From iptech at northrock.bm Wed Aug 1 09:10:31 2012 From: iptech at northrock.bm (iptech) Date: Wed, 01 Aug 2012 11:10:31 -0300 Subject: DOCSIS 3.0 & PPPoE/L2TP compatibility In-Reply-To: <002c01cd6f79$1eb00330$5c100990$@id.au> References: <501678C9.4060604@northrock.bm> <50167F2F.1020901@northrock.bm> <50185895.4040203@northrock.bm> <002c01cd6f79$1eb00330$5c100990$@id.au> Message-ID: <501938D7.6040803@northrock.bm> Hey Michael, Thanks for the feedback. From the scenarios below, I think that option 3 would be more feasible, i.e BSoD L2VPN, via pw. Our max expected number of sessions would not exceed 10k, so probably not an hw limiting issue for us. For option 4, we cannot accommodate this, as we are moving to ASR1K, which does not support PPTP, only L2TP. I am reading through the DOCSIS L2VPN specification to understand the model better. Thanks, On 7/31/2012 9:03 PM, Michael Bowe wrote: > Hi iptech > > As others have said, early Cisco CMTS could do full bridging and/or PPPoE > termination, but newer gear is typically L3 style only. > > For wholesale, the cableco could do one of these : > > * L2 solution : Change your customers to configured as DOCSIS BSoD L2VPN, > and deliver you one dot1q VLAN per customer. You can continue to use PPPoE > with this config (sessions landing directly on your LNS). Gotcha: don't know > about Arris, but Cisco caps you at 4K VLANs per chassis which means this > solution doesn't scale all that well. > > * L2 solution : Change your customers to be setup as DOCSIS BSoD L2VPN, and > deliver you one MPLS pseudowire per customer. You can continue to use PPPoE > with this config (sessions landing directly on your LNS). Gotcha: don't know > about Arris, but Cisco caps you at 16K pw per chassis which means this > solution only provides moderate scaling. Also you have to somehow terminate > all these pw (which are "xconnect"s in Cisco-speak). > > * L3 soution : change your customers to land on a dedicated bundle and VRF. > Apply policy based routing to force-forward all the CPE traffic up a VLAN to > you. If you want to be able to authenticate/count/shape then you probably > need to terminate this traffic as IPoE (Use a dedicated BNG, or maybe you > could try Cisco ISG). Cableco would provide the DHCP for the CM, you would > provide the DHCP for the CPE. CMTS would insert CM MAC as option 82 so you > know which CPE belongs to which CM/customer. > > * L3 solution : last option is to do what they proposed. I would probably > still implement this with a dedicated bundle and VRF. But rather than having > to land the sessions as IPoE, you can now have them come in as PPTP. This > allows you to authenticate/count/shape via your LNS. > > Hope that helps, > Michael. > > From iptech at northrock.bm Wed Aug 1 09:17:09 2012 From: iptech at northrock.bm (iptech) Date: Wed, 01 Aug 2012 11:17:09 -0300 Subject: Fwd: Re: DOCSIS 3.0 & PPPoE/L2TP compatibility In-Reply-To: <5018443C.6010404@ispalliance.net> References: <501843BC.5060700@zcorum.com> <5018443C.6010404@ispalliance.net> Message-ID: <50193A65.3090707@northrock.bm> Hi Scott, Thanks for the feedback, yes this is how I understand it also, however I find it strange that the Cisco platform designated as the future LNS will not accommodate the DOCSIS 3.0requirements - not much collaboration. There is no roadmap for introcducing PPTP on the ASR1K that I can see, so i will not be holding out for one. I am veering towards using a L2 pw solution, but would be interested to hear what you have used in-house yourself to accommodate this change, care to share? Thanks On 7/31/2012 5:46 PM, Scott Helms wrote: > > > > > > > > > > > > I've actually run into this specific problem and the issue your running > into is that at no time was PPPoE part of the DOCSIS specification. It > was supported on several CMTSs because the Cisco UBR shares much of its > OS with more mainline Cisco routers which support L2TP and a host of > other non-DOCSIS related protocols. It was also widely supported on > some of the earliest CMTSs which were bridges instead of routers (then > you needed a separate box to be the LNS). The real problem isn't a > change in DOCSIS version but that they choose a platform that doesn't > share a code base with a general purpose router. This could have been > happenstance or by design, but I can tell you your chances of getting > PPPoE to work at all on that platform (even for the cable operator) are > not high because the box will not operate as a bridge and there is no > (AFAIK) way to relay the PPP discover packets. > > The D3 Arris is either a C4 or a C4C: > http://www.arrisi.com/products/product.asp?id=3 > > On 7/30/2012 8:33 AM, iptech wrote: >> Hi, >> >> We are a small ISP and have a setup in place with the local cable >> company for terminating their users via L2TP for Internet access. >> However they have just announced to us that they are moving to a >> DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE >> via L2TP, and can now only offer PPTP for terminating with us. >> >> We have already begun replacing our Cisco 7206VXR LNS devices with >> Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP >> and PPTP, whereas the ASR1k can do only L2TP. I do not have any >> experience in the cable arena, but from what I have read in the DOCSIS >> standards, each version has maintained backwards compatibility, >> therefore I am very surprised our CableCo has claimed they cannot do >> PPPoE/L2TP anymore. >> >> The CMTS they are currently using is a Cisco, and now they are moving >> to a new ARRIS CMTS. I have not been able to find any information on >> this device and what it can do or not. With the ASR1K marked as the >> natural upgrade path for LNS functions, therefore I cannot believe >> that it is not fully compatible with DOCSIS 3.0. >> >> From what I can tell the only way to accommodate the new CMTS PPTP >> connections will be to terminate them on the legacy 7206VXR, which at >> the end of the day is a backwards step. I would greatly appreciate if >> anyone can give me any pointers and/or suggestions on this matter, so >> I can understand it and move it forward. >> >> FYI: The driver for the CMTS upgrades is to offer higher bandwidth >> access speeds 15mb-20mb. >> >> Thank you. >> >> >> >> >> > > From khelms at ispalliance.net Wed Aug 1 09:23:26 2012 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 01 Aug 2012 10:23:26 -0400 Subject: Fwd: Re: DOCSIS 3.0 & PPPoE/L2TP compatibility In-Reply-To: <50193A65.3090707@northrock.bm> References: <501843BC.5060700@zcorum.com> <5018443C.6010404@ispalliance.net> <50193A65.3090707@northrock.bm> Message-ID: <50193BDE.2030502@ispalliance.net> We ended up using something like this to separate out the traffic at layer 2 for each ISP: http://www.cablelabs.com/cablemodem/downloads/specs/CM-SP-L2VPN-I03-061222.pdf Look at section 5.1.2 Multiple ISP L2VPNs Basically the modems get DHCP & their config from the cable operator but the CPEs get DHCP (and IP connectivity) from the individual ISPs. On 8/1/2012 10:17 AM, iptech wrote: > Hi Scott, > > Thanks for the feedback, > > yes this is how I understand it also, however I find it strange that > the Cisco platform designated as the future LNS will not accommodate > the DOCSIS 3.0requirements - not much collaboration. There is no > roadmap for introcducing PPTP on the ASR1K that I can see, so i will > not be holding out for one. > > I am veering towards using a L2 pw solution, but would be interested > to hear what you have used in-house yourself to accommodate this > change, care to share? > > Thanks > > On 7/31/2012 5:46 PM, Scott Helms wrote: >> >> >> >> >> >> >> >> >> >> >> >> I've actually run into this specific problem and the issue your running >> into is that at no time was PPPoE part of the DOCSIS specification. It >> was supported on several CMTSs because the Cisco UBR shares much of its >> OS with more mainline Cisco routers which support L2TP and a host of >> other non-DOCSIS related protocols. It was also widely supported on >> some of the earliest CMTSs which were bridges instead of routers (then >> you needed a separate box to be the LNS). The real problem isn't a >> change in DOCSIS version but that they choose a platform that doesn't >> share a code base with a general purpose router. This could have been >> happenstance or by design, but I can tell you your chances of getting >> PPPoE to work at all on that platform (even for the cable operator) are >> not high because the box will not operate as a bridge and there is no >> (AFAIK) way to relay the PPP discover packets. >> >> The D3 Arris is either a C4 or a C4C: >> http://www.arrisi.com/products/product.asp?id=3 >> >> On 7/30/2012 8:33 AM, iptech wrote: >>> Hi, >>> >>> We are a small ISP and have a setup in place with the local cable >>> company for terminating their users via L2TP for Internet access. >>> However they have just announced to us that they are moving to a >>> DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE >>> via L2TP, and can now only offer PPTP for terminating with us. >>> >>> We have already begun replacing our Cisco 7206VXR LNS devices with >>> Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP >>> and PPTP, whereas the ASR1k can do only L2TP. I do not have any >>> experience in the cable arena, but from what I have read in the DOCSIS >>> standards, each version has maintained backwards compatibility, >>> therefore I am very surprised our CableCo has claimed they cannot do >>> PPPoE/L2TP anymore. >>> >>> The CMTS they are currently using is a Cisco, and now they are moving >>> to a new ARRIS CMTS. I have not been able to find any information on >>> this device and what it can do or not. With the ASR1K marked as the >>> natural upgrade path for LNS functions, therefore I cannot believe >>> that it is not fully compatible with DOCSIS 3.0. >>> >>> From what I can tell the only way to accommodate the new CMTS PPTP >>> connections will be to terminate them on the legacy 7206VXR, which at >>> the end of the day is a backwards step. I would greatly appreciate if >>> anyone can give me any pointers and/or suggestions on this matter, so >>> I can understand it and move it forward. >>> >>> FYI: The driver for the CMTS upgrades is to offer higher bandwidth >>> access speeds 15mb-20mb. >>> >>> Thank you. >>> >>> >>> >>> >>> >> >> > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From iptech at northrock.bm Wed Aug 1 09:57:03 2012 From: iptech at northrock.bm (iptech) Date: Wed, 01 Aug 2012 11:57:03 -0300 Subject: [c-nsp] DOCSIS 3.0 & PPPoE/L2TP compatibility In-Reply-To: References: <5012D6A3.6070602@northrock.bm> <50146C35.5080006@northrock.bm> <5017F97F.9060407@northrock.bm> Message-ID: <501943BF.1030600@northrock.bm> Ray, Yes PITA indeed. Our 7200 are G2, but we were still planning on moving away from them. I presume you guys are staying on the 7200s meantime, to accomodate the PPTP requirement? Thanks, On 7/31/2012 10:35 PM, Ray Burkholder wrote: > As far as I can tell, and from my conversations with the guys at Cablevision, there isn't anything underhanded. The ARRIS gear simply doesn't do PPPOE stuff. They've looked at various scenarios, and PPTP seems to be the winner. > > Their Cisco CMTS gear was EOL'd a long time ago, and I don't think there is/was a migration path for handling recent DOCSIS and speeds. So they side stepped it. Their ARRIS box is a single chassis with a redundant cards in it. With DOCSIS 3, they get better speeds and stuff out of it. > > I havn't seen the numbers, but I gather it will handily handle all the traffic for all the ISP's. > > It does become a PITA for us as ISP's, as we have to convert all our subscribers over to PPTP. > > What are you doing with your old 7200's? Are they G2's? > > Ray. > >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- >> bounces at puck.nether.net] On Behalf Of iptech >> Sent: Tuesday, July 31, 2012 12:28 >> To: Brian Mengel >> Cc: cisco-nsp at puck.nether.net >> Subject: Re: [c-nsp] DOCSIS 3.0 & PPPoE/L2TP compatibility >> >> Thanks Brian, >> >> I am struggling with this one, as I suspect the cableco are skipping >> round a problem with their in house setup, and trying to make me bend to >> get it working, which I am reluctant to do, as its a big step backwards >> for us. >> >> They are moving from a Cisco CMTS to a Arris, therefore it is highly >> possible this will be a new box. What they have told me is that their >> CMTS setup will now be L3 as opposed to L2. The reasons behind this are >> not clear. >> >> Appreciate any pointers on this one. >> >> Thanks v much. >> >> On 7/31/2012 11:54 AM, Brian Mengel wrote: >>> We run a mix of Cisco and Arris CMTS in our network and have found >>> both to share the same feature set (at least for the features we >>> need). If there is a problem with L2TP its not going to be the result >>> of the DOCSIS 3.0 upgrade but rather an issue with the Arris CMTS. I >>> would recommend getting a technical contact at Arris from your partner >>> MSO and explaining your situation to them and seeing what they can >>> provide as a resolution. Its possible that the Arris outright doesn't >>> support L2TP, but I suspect there may be other things going on. >>> >>> On Sat, Jul 28, 2012 at 6:48 PM, iptech wrote: >>>> Hi, >>>> >>>> No takers? >>>> >>>> Would really appreciate some feedback/pointers. >>>> >>>> Thank you. >>>> >>>> >>>> On 7/27/2012 2:57 PM, iptech wrote: >>>>> Hi, >>>>> >>>>> We are a small ISP and have a setup in place with the local cable >> company >>>>> for terminating their users via L2TP for Internet access. However they >> have >>>>> just announced to us that they are moving to a DOCSIS 3.0 compliant >> setup, >>>>> and this standard no longer supports PPPoE via L2TP, and can now only >> offer >>>>> PPTP for terminating with us. >>>>> >>>>> We have already begun replacing our Cisco 7206VXR LNS devices with >> Cisco >>>>> ASR 1Ks and as you will be aware the older 7206 can do both L2TP and >> PPTP, >>>>> whereas the ASR1k can do only L2TP. >>>>> >>>>> I do not have any experience in the cable arena, but from what I have >> read >>>>> in the DOCSIS standards, each version has maintained backwards >>>>> compatibility, therefore I am very surprised our CableCo has claimed >> they >>>>> cannot do PPPoE/L2TP anymore. >>>>> >>>>> The CMTS they are currently using is a Cisco, and now they are moving to >> a >>>>> new ARRIS CMTS. I have not been able to find any information on this >> device >>>>> and what it can do or not. >>>>> >>>>> With the ASR1K marked as the natural upgrade path for LNS functions, >>>>> therefore I cannot believe that it is not fully compatible with DOCSIS 3.0. >>>>> >>>>> From what I can tell the only way to accommodate the new CMTS PPTP >>>>> connections will be to terminate them on the legacy 7206VXR, which at >> the >>>>> end of the day is a backwards step. >>>>> >>>>> I would greatly appreciate if anyone can give me any pointers and/or >>>>> suggestions on this matter, so I can understand it and move it forward. >>>>> >>>>> FYI: The driver for the CMTS upgrades is to offer higher bandwidth >> access >>>>> speeds 15mb-20mb. >>>>> >>>>> Thank you. >>>>> >>>>> _______________________________________________ >>>>> cisco-nsp mailing list cisco-nsp at puck.nether.net >>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>>>> >>>> _______________________________________________ >>>> cisco-nsp mailing list cisco-nsp at puck.nether.net >>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > From khelms at ispalliance.net Wed Aug 1 10:23:29 2012 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 01 Aug 2012 11:23:29 -0400 Subject: [c-nsp] DOCSIS 3.0 & PPPoE/L2TP compatibility In-Reply-To: <501943BF.1030600@northrock.bm> References: <5012D6A3.6070602@northrock.bm> <50146C35.5080006@northrock.bm> <5017F97F.9060407@northrock.bm> <501943BF.1030600@northrock.bm> Message-ID: <501949F1.9040708@ispalliance.net> I did PPPoE for open access on cable networks starting back in DOCSIS 1.0 and that (and PPTP for that matter) is a dead end IMO. Get to BSoD/TLS which is a CableLabs (the guys who write and test the DOCSIS spec) standard and will be supported on all of the D3 chassis no matter if its Arris, Cisco, Motorola, or Casa. The guys at the cable company could have gone with a Cisco 10k or a 7225(smaller systems only) and I believe both of those still support being a LNS for PPPoE, but again Cisco is really the only one and good luck getting any help from their TAC on setting it up. On 8/1/2012 10:57 AM, iptech wrote: > Ray, > > Yes PITA indeed. > > Our 7200 are G2, but we were still planning on moving away from them. > > I presume you guys are staying on the 7200s meantime, to accomodate > the PPTP requirement? > > Thanks, > > On 7/31/2012 10:35 PM, Ray Burkholder wrote: >> As far as I can tell, and from my conversations with the guys at >> Cablevision, there isn't anything underhanded. The ARRIS gear simply >> doesn't do PPPOE stuff. They've looked at various scenarios, and PPTP >> seems to be the winner. >> >> Their Cisco CMTS gear was EOL'd a long time ago, and I don't think >> there is/was a migration path for handling recent DOCSIS and >> speeds. So they side stepped it. Their ARRIS box is a single >> chassis with a redundant cards in it. With DOCSIS 3, they get better >> speeds and stuff out of it. >> >> I havn't seen the numbers, but I gather it will handily handle all >> the traffic for all the ISP's. >> >> It does become a PITA for us as ISP's, as we have to convert all >> our subscribers over to PPTP. >> >> What are you doing with your old 7200's? Are they G2's? >> >> Ray. >> >>> -----Original Message----- >>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- >>> bounces at puck.nether.net] On Behalf Of iptech >>> Sent: Tuesday, July 31, 2012 12:28 >>> To: Brian Mengel >>> Cc: cisco-nsp at puck.nether.net >>> Subject: Re: [c-nsp] DOCSIS 3.0 & PPPoE/L2TP compatibility >>> >>> Thanks Brian, >>> >>> I am struggling with this one, as I suspect the cableco are skipping >>> round a problem with their in house setup, and trying to make me >>> bend to >>> get it working, which I am reluctant to do, as its a big step backwards >>> for us. >>> >>> They are moving from a Cisco CMTS to a Arris, therefore it is highly >>> possible this will be a new box. What they have told me is that their >>> CMTS setup will now be L3 as opposed to L2. The reasons behind this are >>> not clear. >>> >>> Appreciate any pointers on this one. >>> >>> Thanks v much. >>> >>> On 7/31/2012 11:54 AM, Brian Mengel wrote: >>>> We run a mix of Cisco and Arris CMTS in our network and have found >>>> both to share the same feature set (at least for the features we >>>> need). If there is a problem with L2TP its not going to be the result >>>> of the DOCSIS 3.0 upgrade but rather an issue with the Arris CMTS. I >>>> would recommend getting a technical contact at Arris from your partner >>>> MSO and explaining your situation to them and seeing what they can >>>> provide as a resolution. Its possible that the Arris outright doesn't >>>> support L2TP, but I suspect there may be other things going on. >>>> >>>> On Sat, Jul 28, 2012 at 6:48 PM, iptech wrote: >>>>> Hi, >>>>> >>>>> No takers? >>>>> >>>>> Would really appreciate some feedback/pointers. >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> On 7/27/2012 2:57 PM, iptech wrote: >>>>>> Hi, >>>>>> >>>>>> We are a small ISP and have a setup in place with the local cable >>> company >>>>>> for terminating their users via L2TP for Internet access. However >>>>>> they >>> have >>>>>> just announced to us that they are moving to a DOCSIS 3.0 compliant >>> setup, >>>>>> and this standard no longer supports PPPoE via L2TP, and can now >>>>>> only >>> offer >>>>>> PPTP for terminating with us. >>>>>> >>>>>> We have already begun replacing our Cisco 7206VXR LNS devices with >>> Cisco >>>>>> ASR 1Ks and as you will be aware the older 7206 can do both L2TP and >>> PPTP, >>>>>> whereas the ASR1k can do only L2TP. >>>>>> >>>>>> I do not have any experience in the cable arena, but from what I >>>>>> have >>> read >>>>>> in the DOCSIS standards, each version has maintained backwards >>>>>> compatibility, therefore I am very surprised our CableCo has claimed >>> they >>>>>> cannot do PPPoE/L2TP anymore. >>>>>> >>>>>> The CMTS they are currently using is a Cisco, and now they are >>>>>> moving to >>> a >>>>>> new ARRIS CMTS. I have not been able to find any information on this >>> device >>>>>> and what it can do or not. >>>>>> >>>>>> With the ASR1K marked as the natural upgrade path for LNS functions, >>>>>> therefore I cannot believe that it is not fully compatible with >>>>>> DOCSIS 3.0. >>>>>> >>>>>> From what I can tell the only way to accommodate the new CMTS PPTP >>>>>> connections will be to terminate them on the legacy 7206VXR, >>>>>> which at >>> the >>>>>> end of the day is a backwards step. >>>>>> >>>>>> I would greatly appreciate if anyone can give me any pointers and/or >>>>>> suggestions on this matter, so I can understand it and move it >>>>>> forward. >>>>>> >>>>>> FYI: The driver for the CMTS upgrades is to offer higher bandwidth >>> access >>>>>> speeds 15mb-20mb. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> cisco-nsp mailing list cisco-nsp at puck.nether.net >>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>>>>> >>>>> _______________________________________________ >>>>> cisco-nsp mailing list cisco-nsp at puck.nether.net >>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> _______________________________________________ >>> cisco-nsp mailing list cisco-nsp at puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >> > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From robertg at garlic.com Wed Aug 1 12:51:10 2012 From: robertg at garlic.com (Robert Glover) Date: Wed, 01 Aug 2012 10:51:10 -0700 Subject: UCSF Network Admin?? Message-ID: <50196C8E.60100@garlic.com> Hello, Is there anyone with clue from UCSF on-list? Or if someone knows how to put me in contact with them, that would be great. We are not able to query their DNS servers from our network. We've got users not able to access anything UCSF due to this. Thus far, their response has been to manually put DNS entries into our users hosts file, not actually fix the real issue. Thanks, -Robert From henry at hup.org Wed Aug 1 13:07:47 2012 From: henry at hup.org (Henry Stryker) Date: Wed, 01 Aug 2012 11:07:47 -0700 Subject: UCSF Network Admin?? In-Reply-To: <50196C8E.60100@garlic.com> References: <50196C8E.60100@garlic.com> Message-ID: <50197073.5040701@hup.org> On 08/01/12 10:51 , Robert Glover wrote: > We are not able to query their DNS servers from our network. We've got > users not able to access anything UCSF due to this. I am querying them OK. I am in US AZ. I am also able to reach manana.garlic.com. [hyperion]/usr/local# dig www.ucsf.edu @ucsfns2.ucsf.edu www.ucsf.edu. 3600 IN A 64.54.132.50 ucsf.edu. 3600 IN NS ucsfns1.ucsf.edu. ucsf.edu. 3600 IN NS adns2.Berkeley.edu. ucsf.edu. 3600 IN NS adns1.Berkeley.edu. ucsf.edu. 3600 IN NS ucsfns2.ucsf.edu. adns1.Berkeley.edu. 172800 IN A 128.32.136.3 adns1.Berkeley.edu. 3600 IN AAAA 2607:f140:ffff:fffe::3 adns2.Berkeley.edu. 172800 IN A 128.32.136.14 adns2.Berkeley.edu. 3600 IN AAAA 2607:f140:ffff:fffe::e ucsfns1.ucsf.edu. 3600 IN A 128.218.254.10 ucsfns2.ucsf.edu. 3600 IN A 128.218.254.40 ;; Query time: 41 msec ;; SERVER: 128.218.254.40#53(128.218.254.40) ;; WHEN: Wed Aug 1 11:02:46 2012 ;; MSG SIZE rcvd: 270 From shortdudey123 at gmail.com Wed Aug 1 13:49:36 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 1 Aug 2012 13:49:36 -0500 Subject: UCSF Network Admin?? In-Reply-To: <50197073.5040701@hup.org> References: <50196C8E.60100@garlic.com> <50197073.5040701@hup.org> Message-ID: Ditto on that from TWTC in Milwaukee, WI. # dig www.ucsf.edu @ucsfns2.ucsf.edu ; <<>> DiG 9.8.1-P1 <<>> www.ucsf.edu @ucsfns2.ucsf.edu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49793 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.ucsf.edu. IN A ;; ANSWER SECTION: www.ucsf.edu. 3600 IN A 64.54.132.50 ;; AUTHORITY SECTION: ucsf.edu. 3600 IN NS adns1.Berkeley.edu. ucsf.edu. 3600 IN NS ucsfns2.ucsf.edu. ucsf.edu. 3600 IN NS adns2.Berkeley.edu. ucsf.edu. 3600 IN NS ucsfns1.ucsf.edu. ;; ADDITIONAL SECTION: adns1.Berkeley.edu. 172800 IN A 128.32.136.3 adns1.Berkeley.edu. 3600 IN AAAA 2607:f140:ffff:fffe::3 adns2.Berkeley.edu. 172800 IN A 128.32.136.14 adns2.Berkeley.edu. 3600 IN AAAA 2607:f140:ffff:fffe::e ucsfns1.ucsf.edu. 3600 IN A 128.218.254.10 ucsfns2.ucsf.edu. 3600 IN A 128.218.254.40 ;; Query time: 63 msec ;; SERVER: 128.218.254.40#53(128.218.254.40) ;; WHEN: Wed Aug 1 13:48:51 2012 ;; MSG SIZE rcvd: 259 On Wed, Aug 1, 2012 at 1:07 PM, Henry Stryker wrote: > > > On 08/01/12 10:51 , Robert Glover wrote: > > We are not able to query their DNS servers from our network. We've got > > users not able to access anything UCSF due to this. > > > I am querying them OK. I am in US AZ. I am also able to reach > manana.garlic.com. > > [hyperion]/usr/local# dig www.ucsf.edu @ucsfns2.ucsf.edu > www.ucsf.edu. 3600 IN A 64.54.132.50 > ucsf.edu. 3600 IN NS ucsfns1.ucsf.edu. > ucsf.edu. 3600 IN NS adns2.Berkeley.edu. > ucsf.edu. 3600 IN NS adns1.Berkeley.edu. > ucsf.edu. 3600 IN NS ucsfns2.ucsf.edu. > adns1.Berkeley.edu. 172800 IN A 128.32.136.3 > adns1.Berkeley.edu. 3600 IN AAAA 2607:f140:ffff:fffe::3 > adns2.Berkeley.edu. 172800 IN A 128.32.136.14 > adns2.Berkeley.edu. 3600 IN AAAA 2607:f140:ffff:fffe::e > ucsfns1.ucsf.edu. 3600 IN A 128.218.254.10 > ucsfns2.ucsf.edu. 3600 IN A 128.218.254.40 > ;; Query time: 41 msec > ;; SERVER: 128.218.254.40#53(128.218.254.40) > ;; WHEN: Wed Aug 1 11:02:46 2012 > ;; MSG SIZE rcvd: 270 > > From ryanczak at gmail.com Wed Aug 1 14:21:33 2012 From: ryanczak at gmail.com (Matt Ryanczak) Date: Wed, 01 Aug 2012 15:21:33 -0400 Subject: dnsmadeeasy.com Message-ID: <501981BD.3070508@gmail.com> Looking for experiences regarding their DNS hosting services. Anyone have a story to share? Off-list replies would be great. thanks, ~matt From bmengel at gmail.com Wed Aug 1 14:40:12 2012 From: bmengel at gmail.com (Brian Mengel) Date: Wed, 1 Aug 2012 15:40:12 -0400 Subject: Fwd: Re: DOCSIS 3.0 & PPPoE/L2TP compatibility In-Reply-To: <50193A65.3090707@northrock.bm> References: <501843BC.5060700@zcorum.com> <5018443C.6010404@ispalliance.net> <50193A65.3090707@northrock.bm> Message-ID: One thing to be mindful of is that BSoD support may not be prevelant in the installed modem base of your MSO. Replacing those modems would be costly for someone. On Wed, Aug 1, 2012 at 10:17 AM, iptech wrote: > Hi Scott, > > Thanks for the feedback, > > yes this is how I understand it also, however I find it strange that the > Cisco platform designated as the future LNS will not accommodate the DOCSIS > 3.0requirements - not much collaboration. There is no roadmap for > introcducing PPTP on the ASR1K that I can see, so i will not be holding out > for one. > > I am veering towards using a L2 pw solution, but would be interested to hear > what you have used in-house yourself to accommodate this change, care to > share? > > Thanks > > > On 7/31/2012 5:46 PM, Scott Helms wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> I've actually run into this specific problem and the issue your running >> into is that at no time was PPPoE part of the DOCSIS specification. It >> was supported on several CMTSs because the Cisco UBR shares much of its >> OS with more mainline Cisco routers which support L2TP and a host of >> other non-DOCSIS related protocols. It was also widely supported on >> some of the earliest CMTSs which were bridges instead of routers (then >> you needed a separate box to be the LNS). The real problem isn't a >> change in DOCSIS version but that they choose a platform that doesn't >> share a code base with a general purpose router. This could have been >> happenstance or by design, but I can tell you your chances of getting >> PPPoE to work at all on that platform (even for the cable operator) are >> not high because the box will not operate as a bridge and there is no >> (AFAIK) way to relay the PPP discover packets. >> >> The D3 Arris is either a C4 or a C4C: >> http://www.arrisi.com/products/product.asp?id=3 >> >> On 7/30/2012 8:33 AM, iptech wrote: >>> >>> Hi, >>> >>> We are a small ISP and have a setup in place with the local cable >>> company for terminating their users via L2TP for Internet access. >>> However they have just announced to us that they are moving to a >>> DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE >>> via L2TP, and can now only offer PPTP for terminating with us. >>> >>> We have already begun replacing our Cisco 7206VXR LNS devices with >>> Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP >>> and PPTP, whereas the ASR1k can do only L2TP. I do not have any >>> experience in the cable arena, but from what I have read in the DOCSIS >>> standards, each version has maintained backwards compatibility, >>> therefore I am very surprised our CableCo has claimed they cannot do >>> PPPoE/L2TP anymore. >>> >>> The CMTS they are currently using is a Cisco, and now they are moving >>> to a new ARRIS CMTS. I have not been able to find any information on >>> this device and what it can do or not. With the ASR1K marked as the >>> natural upgrade path for LNS functions, therefore I cannot believe >>> that it is not fully compatible with DOCSIS 3.0. >>> >>> From what I can tell the only way to accommodate the new CMTS PPTP >>> connections will be to terminate them on the legacy 7206VXR, which at >>> the end of the day is a backwards step. I would greatly appreciate if >>> anyone can give me any pointers and/or suggestions on this matter, so >>> I can understand it and move it forward. >>> >>> FYI: The driver for the CMTS upgrades is to offer higher bandwidth >>> access speeds 15mb-20mb. >>> >>> Thank you. >>> >>> >>> >>> >>> >> >> > > From mathews at hawaii.edu Wed Aug 1 14:50:55 2012 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Wed, 01 Aug 2012 15:50:55 -0400 Subject: Fyi... In-Reply-To: <501987F4.90909@hawaii.edu> References: <501987F4.90909@hawaii.edu> Message-ID: <5019889F.4090702@hawaii.edu> It it is of interest... https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group All the best. -- /************************************************ * Dr. Robert Mathews, D.Phil. * Distinguished Senior Research Scholar * National Security Affairs & U.S Industrial Preparedness * Office of Scientific Inquiry and Applications * University of Hawai'i * E.mail: mathews at hawaii dot edu/ From marka at isc.org Wed Aug 1 17:03:07 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 02 Aug 2012 08:03:07 +1000 Subject: UCSF Network Admin?? In-Reply-To: Your message of "Wed, 01 Aug 2012 10:51:10 MST." <50196C8E.60100@garlic.com> References: <50196C8E.60100@garlic.com> Message-ID: <20120801220308.257DB232CDC9@drugs.dv.isc.org> In message <50196C8E.60100 at garlic.com>, Robert Glover writes: > Hello, > > Is there anyone with clue from UCSF on-list? Or if someone knows how to > put me in contact with them, that would be great. > > We are not able to query their DNS servers from our network. We've got > users not able to access anything UCSF due to this. > > Thus far, their response has been to manually put DNS entries into our > users hosts file, not actually fix the real issue. Please, please don't misuse "DNS entries". Host files DO NOT and NEVER HAVE taken "DNS entries". The contain hostname/address mappings but they are not and never bave been DNS entries. > Thanks, > -Robert > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From robertg at garlic.com Wed Aug 1 18:22:48 2012 From: robertg at garlic.com (Robert Glover) Date: Wed, 01 Aug 2012 16:22:48 -0700 Subject: UCSF Network Admin?? In-Reply-To: <50196C8E.60100@garlic.com> References: <50196C8E.60100@garlic.com> Message-ID: <5019BA48.1030501@garlic.com> On 08/01/2012 10:51 AM, Robert Glover wrote: > Hello, > > Is there anyone with clue from UCSF on-list? Or if someone knows how to > put me in contact with them, that would be great. > > We are not able to query their DNS servers from our network. We've got > users not able to access anything UCSF due to this. > > Thus far, their response has been to manually put DNS entries into our > users hosts file, not actually fix the real issue. > > Thanks, > -Robert > I should have been a little more forthcoming with information. We are having issues with getting responses from these servers: NSMEDCTR1.UCSFMEDICALCENTER.ORG NSMEDCTR2.UCSFMEDICALCENTER.ORG Which are authoritative for "ucsfmedctr.org" and "ucsfmedicalcenter.org". We ARE able to resolve ucsf.edu and things associated with that entity, just NOT the medical center. Thanks, -Robert From yuksem at cse.unr.edu Wed Aug 1 18:27:56 2012 From: yuksem at cse.unr.edu (Murat Yuksel) Date: Wed, 1 Aug 2012 16:27:56 -0700 Subject: cost of misconfigurations In-Reply-To: <5019BA48.1030501@garlic.com> References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: Hi all, I am looking for literature on the (monetary) costs of misconfigurations in an operational ISP network. Are there any such studies I can benefit from? In a larger context, are there any thorough studies exploring the cost of building and running a large ISP network? Best, -Murat ======================================== Murat Yuksel Associate Professor Graduate Director Department of Computer Science and Engineering University of Nevada, Reno 1664 N. Virginia Street, MS 171, Reno, NV 89557. Phone: +1 (775) 327 2246, Fax: +1 (775) 784 1877 E-mail: yuksem at cse.unr.edu Web: http://www.cse.unr.edu/~yuksem ======================================== From diogo.montagner at gmail.com Wed Aug 1 19:08:56 2012 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Thu, 2 Aug 2012 08:08:56 +0800 Subject: cost of misconfigurations In-Reply-To: References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: Hi Murat, I never saw any literature about this topic. But I think it is not too difficult to calculate (or estimate). A misconfiguration will, at least, impact on two points: network outage and re-work. For the network outage, you have to use the SLAs to calculate the cost (how much you lost from the customers' revenue) due to that outage. On the other hand, there is the time efforts spent to fix the misconfiguration. Under the fix, it could be removing the misconfig and applying a new one correct. Or just fixing the misconfig targeting the correct config. This re-work will translate in time, and time can be translated in money spent. Regards On 8/2/12, Murat Yuksel wrote: > Hi all, > > I am looking for literature on the (monetary) costs of misconfigurations in > an operational ISP network. Are there any such studies I can benefit from? > > In a larger context, are there any thorough studies exploring the cost of > building and running a large ISP network? > > Best, > > -Murat > ======================================== > Murat Yuksel > Associate Professor > Graduate Director > Department of Computer Science and Engineering > University of Nevada, Reno > 1664 N. Virginia Street, MS 171, Reno, NV 89557. > Phone: +1 (775) 327 2246, Fax: +1 (775) 784 1877 > E-mail: yuksem at cse.unr.edu > Web: http://www.cse.unr.edu/~yuksem > ======================================== > > -- Sent from my mobile device ./diogo -montagner JNCIE-SP 0x41A From djahandarie at gmail.com Wed Aug 1 19:13:38 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Wed, 1 Aug 2012 20:13:38 -0400 Subject: cost of misconfigurations In-Reply-To: References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: On Wed, Aug 1, 2012 at 8:08 PM, Diogo Montagner wrote: > A misconfiguration will, at least, impact on two points: network > outage and re-work. For the network outage, you have to use the SLAs > to calculate the cost (how much you lost from the customers' revenue) > due to that outage. On the other hand, there is the time efforts spent > to fix the misconfiguration. Under the fix, it could be removing the > misconfig and applying a new one correct. Or just fixing the misconfig > targeting the correct config. This re-work will translate in time, and > time can be translated in money spent. Isn't the largest cost omitted (or at least glossed over) here? Namely, lost customers due to the outage. That's why people have SLAs and rework the network at all -- to avoid that cost. -- Darius Jahandarie From randy at psg.com Wed Aug 1 19:23:06 2012 From: randy at psg.com (Randy Bush) Date: Wed, 01 Aug 2012 17:23:06 -0700 Subject: cost of misconfigurations In-Reply-To: References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: > I am looking for literature on the (monetary) costs of > misconfigurations in an operational ISP network. Are there any such > studies I can benefit from? jgs, who should know, says 42 quatloos randy From diogo.montagner at gmail.com Wed Aug 1 19:32:19 2012 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Thu, 2 Aug 2012 08:32:19 +0800 Subject: cost of misconfigurations In-Reply-To: References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: Hi Darius, You are right. The lost of a customer due to those things. However, I would classify this as an unknown situation (in terms of risk analisys) because the others I mentioned are possible to calculate and estimate (they are known). But it is very hard to estimate if a customer will cancel the contract because 1 or n network outages. In theory, if the customer SLA is not being met consecutively, there is a potential probability he will cancel the contract. Regards On 8/2/12, Darius Jahandarie wrote: > On Wed, Aug 1, 2012 at 8:08 PM, Diogo Montagner > wrote: >> A misconfiguration will, at least, impact on two points: network >> outage and re-work. For the network outage, you have to use the SLAs >> to calculate the cost (how much you lost from the customers' revenue) >> due to that outage. On the other hand, there is the time efforts spent >> to fix the misconfiguration. Under the fix, it could be removing the >> misconfig and applying a new one correct. Or just fixing the misconfig >> targeting the correct config. This re-work will translate in time, and >> time can be translated in money spent. > > Isn't the largest cost omitted (or at least glossed over) here? > Namely, lost customers due to the outage. That's why people have SLAs > and rework the network at all -- to avoid that cost. > > > -- > Darius Jahandarie > -- Sent from my mobile device ./diogo -montagner JNCIE-SP 0x41A From henry at hup.org Wed Aug 1 19:44:22 2012 From: henry at hup.org (Henry Stryker) Date: Wed, 01 Aug 2012 17:44:22 -0700 Subject: UCSF Network Admin?? In-Reply-To: <5019BA48.1030501@garlic.com> References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: <5019CD66.8050702@hup.org> On 08/01/12 16:22 , Robert Glover wrote: > We are having issues with getting responses from these servers: > > NSMEDCTR1.UCSFMEDICALCENTER.ORG > NSMEDCTR2.UCSFMEDICALCENTER.ORG > > Which are authoritative for "ucsfmedctr.org" and "ucsfmedicalcenter.org". Those servers respond to my queries from here in AZ: # dig www.ucsfmedicalcenter.org @nsmedctr2.ucsfmedicalcenter.org www.ucsfmedicalcenter.org. 86400 IN CNAME webmcb06.ucsfmedicalcenter.org. webmcb06.ucsfmedicalcenter.org. 86400 IN A 64.54.46.99 ;; Query time: 41 msec ;; SERVER: 64.54.50.50#53(64.54.50.50) ;; WHEN: Wed Aug 1 17:36:36 2012 ;; MSG SIZE rcvd: 93 # dig www.ucsfmedicalcenter.org @nsmedctr1.ucsfmedicalcenter.org www.ucsfmedicalcenter.org. 86400 IN CNAME webmcb06.ucsfmedicalcenter.org. webmcb06.ucsfmedicalcenter.org. 86400 IN A 64.54.46.99 ;; Query time: 54 msec ;; SERVER: 64.54.42.50#53(64.54.42.50) ;; WHEN: Wed Aug 1 17:37:41 2012 ;; MSG SIZE rcvd: 93 From marine64 at gmail.com Wed Aug 1 19:47:44 2012 From: marine64 at gmail.com (Brian Henson) Date: Wed, 1 Aug 2012 20:47:44 -0400 Subject: UCSF Network Admin?? In-Reply-To: <5019CD66.8050702@hup.org> References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> <5019CD66.8050702@hup.org> Message-ID: also responds here in Ohio on TW On Wed, Aug 1, 2012 at 8:44 PM, Henry Stryker wrote: > > > On 08/01/12 16:22 , Robert Glover wrote: > > We are having issues with getting responses from these servers: > > > > NSMEDCTR1.UCSFMEDICALCENTER.ORG > > NSMEDCTR2.UCSFMEDICALCENTER.ORG > > > > Which are authoritative for "ucsfmedctr.org" and "ucsfmedicalcenter.org > ". > > > Those servers respond to my queries from here in AZ: > > # dig www.ucsfmedicalcenter.org @nsmedctr2.ucsfmedicalcenter.org > www.ucsfmedicalcenter.org. 86400 IN CNAME > webmcb06.ucsfmedicalcenter.org. > webmcb06.ucsfmedicalcenter.org. 86400 IN A 64.54.46.99 > ;; Query time: 41 msec > ;; SERVER: 64.54.50.50#53(64.54.50.50) > ;; WHEN: Wed Aug 1 17:36:36 2012 > ;; MSG SIZE rcvd: 93 > > # dig www.ucsfmedicalcenter.org @nsmedctr1.ucsfmedicalcenter.org > www.ucsfmedicalcenter.org. 86400 IN CNAME > webmcb06.ucsfmedicalcenter.org. > webmcb06.ucsfmedicalcenter.org. 86400 IN A 64.54.46.99 > ;; Query time: 54 msec > ;; SERVER: 64.54.42.50#53(64.54.42.50) > ;; WHEN: Wed Aug 1 17:37:41 2012 > ;; MSG SIZE rcvd: 93 > > From mysidia at gmail.com Wed Aug 1 20:14:39 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 1 Aug 2012 20:14:39 -0500 Subject: cost of misconfigurations In-Reply-To: References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: On 8/1/12, Diogo Montagner wrote: I think it's more complicated than that, the cost of misconfiguration is almost inseparable in some cases from the cost of configuration in general.; not all misconfigs are equal, so you might want to concentrate on a specific kind of misconfiguration, or a specific misconfig impact "E.g. an erroneous filter is applied, causing routes to be accepted from an EGP peer without restriction". Esp. with misconfigurations that might not have an immediately discovered impact, business impact beyond cost to discover and resolve may not be apparent, which depend on details of the misconfig, such as how trivial or 'obvious' the error should be, how consistent the problems it causes. At least if you concetrate on a certain specific type of misconfig and specific impact, you can have a basis for comparison and approximation, for just that type though. The "fix" to some types of misconfigs might sometimes be to update the design documentation, so the "misconfig" is no longer a misconfiguration; so then you can start asking about how you define "misconfig" in the first place, and the costs of having erroneous or missing documentation. Which is hard, because the "costs" of updating documentation and finding errors, less than best/optimal practices, or improvements possible in configurations, are effected by long term "costs" or loss of efficiencies resulting from failing to correct documentation, and failing to review and improve arguably suboptimal configurations. Some misconfigs or suboptimal configs are discovered by review or other measures before there is any operational impact. Some misconfigs are "safe" or "harmless" by coincidence, but can cause issues later when the network is expanded farther according to design that does not anticipate the misconfig, so the cost there is increased risk. Not all possible misconfigurations of a network cause an outage, some misconfigurations are actually design errors, not operator errors; not all network issues are outages, some configuration errors are just things like "Some entries in an access-list that are dead-weight, e.g. can never be reached, or is not necessary"; and the impact of this error is wasted memory resources, or increased complexity / more unnecessary stuff for humans to look at. (The entry might not have been dead-weight when originally added.) Correcting the deadweight ACL entry situation then is an improvement in efficiency. Not all misconfigurations are detected, either, possibly, sometimes even misconfigs that caused issues. An example of a misconfiguration that would occur frequently in some kinds of environments and might not break an uptime SLA, would be suboptimal performance, less cost-effectiveness (E.g. early upgrade required due to an unrecognized misconfiguration). Or configuration deadweight utilizing so much memory, that hardware upgrades become needed. On some networks, there might not be a formal SLA, and the end user might not notice or take issue with it. Loss of fault resilience (E.g. failover path won't work); no SLA is violated if the fault tolerance wasn't required by the SLA, and the configuration error might go undetected for years if there was not regular failover testing performed. It might be corrected before there is an issue... then the cost of "Increased risk" during the period, in which the misconfig wasn't service-effecting could be quite nebulous. > I never saw any literature about this topic. But I think it is not too > difficult to calculate (or estimate). [snip] > A misconfiguration will, at least, impact on two points: network > outage and re-work. For the network outage, you have to use the SLAs > to calculate the cost (how much you lost from the customers' revenue) > due to that outage. On the other hand, there is the time efforts spent > to fix the misconfiguration. Under the fix, it could be removing the [snip] -- -JH From george.herbert at gmail.com Wed Aug 1 20:16:39 2012 From: george.herbert at gmail.com (George Herbert) Date: Wed, 1 Aug 2012 18:16:39 -0700 Subject: cost of misconfigurations In-Reply-To: References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: On Wed, Aug 1, 2012 at 5:32 PM, Diogo Montagner wrote: > Hi Darius, > > You are right. The lost of a customer due to those things. However, I > would classify this as an unknown situation (in terms of risk > analisys) because the others I mentioned are possible to calculate and > estimate (they are known). But it is very hard to estimate if a > customer will cancel the contract because 1 or n network outages. In > theory, if the customer SLA is not being met consecutively, there is a > potential probability he will cancel the contract. > > Regards On the end customer side, I've done a bunch of reliability / risk cost assessments for various customers over the years. It's never easy. For an ISP... customers are fairly locked in, but for big networks and customers, especially multihoming customers, business goes where they want it. SLA costs are easy. Predicting the final financial impact is hard. -- -george william herbert george.herbert at gmail.com From frogstarr78 at gmail.com Wed Aug 1 21:00:20 2012 From: frogstarr78 at gmail.com (Scott Noel-Hemming) Date: Wed, 01 Aug 2012 19:00:20 -0700 Subject: Update from the NANOG Communications Committee regarding recent off-topic posts In-Reply-To: <8929F2FB-6E61-41D9-9C39-621127F2929D@sonn.com> References: <20120728163636.49bf4f44@segv> <20120730190436.8988.L@m.l.vaunt.eu> <20721.1343669735@turing-police.cc.vt.edu> <8679FADA-327F-4586-928D-006A054E3686@ianai.net> <8929F2FB-6E61-41D9-9C39-621127F2929D@sonn.com> Message-ID: <5019DF34.6020402@gmail.com> On 07/30/2012 10:57 AM, Steven Noble wrote: > The fix for this issue is trivial. Every new signup should require a sponsor or a deposit of funds into a new member fund. Once a member has made a relevant post regarding a NANOG related item their funds are returned. > > If someone spams they forfeit the money and it is used to help defray the costs of attending NANOG for the 99%. > > If the poster has been sponsored by a current member, said member is flogged in public at the next meeting. > > ...runs > > Sent from my iPhone > > On Jul 30, 2012, at 10:42 AM, "Patrick W. Gilmore" wrote: > >> I'm sorry Panashe is upset by this rule. Interestingly, "Your search - Panashe Flack nanog - did not match any documents." So my guess is that a post from that account has not happened before, meaning the post was moderated yet still made it through. >> >> Has anyone done a data mining experiment to see how many posts a month are from "new" members? My guess is it is a trivial percentage. >> >> -- >> TTFN, >> patrick >> >> >> On Jul 30, 2012, at 13:35 , valdis.kletnieks at vt.edu wrote: >>> On Mon, 30 Jul 2012 21:04:36 +0200, Panashe Flack said: >>>> list for continued activity. And just for reference - have you guys >>>> SEEN the "Linux Kernel Mailing List"? - it gets frequent spam posts >>>> and yet is perfectly able to ignore the spam/irrelevant posts and >>>> continue on its remit. >>> For those who don't drink from the Linux-Kernel firehose, it averages >>> 1 or 2 spams per day - and anywhere from 500 to 700 postings a day. >>> >>> As Linus Torvalds said, back when it was averaging 200 a day: >>> >>> "Note that nobody reads every post in linux-kernel. In fact, nobody who >>> expects to have time left over to actually do any real kernel work will >>> read even half. Except Alan Cox, but he's actually not human, but about >>> a thousand gnomes working in under-ground caves in Swansea. None of the >>> individual gnomes read all the postings either, they just work together >>> really well." >>> >>> The list managers do an incredible job of stopping spam - but even if >>> 50 or 75 a day got through, they'd just be lost in the noise. You're skipping >>> several hundred messages a day, skipping a few more isn't any different. >>> >> Would be an iPhone user to suggest such an idea. Thanks for not implementing this so us peons can learn a thing or two, too. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From steve at pirk.com Wed Aug 1 21:32:15 2012 From: steve at pirk.com (steve pirk [egrep]) Date: Wed, 1 Aug 2012 19:32:15 -0700 Subject: Fyi... In-Reply-To: <5019889F.4090702@hawaii.edu> References: <501987F4.90909@hawaii.edu> <5019889F.4090702@hawaii.edu> Message-ID: On Wed, Aug 1, 2012 at 12:50 PM, Robert Mathews (OSIA) wrote: > > It it is of interest... > > > https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group I was not aware of this limitation. Android and other Chrome devices do not have issues like these. Wow. --steve From mathews at hawaii.edu Wed Aug 1 23:00:35 2012 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Thu, 02 Aug 2012 00:00:35 -0400 Subject: Fyi... In-Reply-To: References: <501987F4.90909@hawaii.edu> <5019889F.4090702@hawaii.edu> Message-ID: <5019FB63.8060909@hawaii.edu> On 8/1/2012 10:32 PM, steve pirk [egrep] wrote: > On Wed, Aug 1, 2012 at 12:50 PM, Robert Mathews (OSIA) > > wrote: > > > It it is of interest... > > https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group > > > > I was not aware of this limitation. Android and other Chrome devices > do not have issues like these. Wow. > > --steve If this subject is of interest to you/your organization, you might consider signing the petition. Although this started as an academy based effort, Lee Badman of Syracuse University as originator, welcomes all parties who appreciates the impact of the problem - to sign on. All the best -- /************************************************ * Dr. Robert Mathews, D.Phil. * Distinguished Senior Research Scholar * National Security Affairs & U.S Industrial Preparedness * Office of Scientific Inquiry and Applications * University of Hawai'i * E.mail: mathews at hawaii dot edu/ From simon.knight at gmail.com Wed Aug 1 23:22:02 2012 From: simon.knight at gmail.com (Simon Knight) Date: Thu, 2 Aug 2012 13:52:02 +0930 Subject: cost of misconfigurations In-Reply-To: References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: Quantifying the business costs would be very complex. Here are some reports and research papers that may be a starting point: [1] Juniper Networks, Inc., ?What's Behind Network Downtime?,? pp. 1?12, May 2008. [2] R. Mahajan, D. Wetherall, and T. Anderson, ?Understanding BGP misconfiguration,? Proceedings of the 2002 conference on Applications, 2002. [3] A. Medem, R. Teixeira, N. Feamster, and M. Meulle, ?Joint analysis of network incidents and intradomain routing changes,? Network and Service Management (CNSM), 2010 International Conference on, pp. 198?205, 2010. [4] D. Turner, K. Levchenko, A. C. Snoeren, and S. Savage, ?California fault lines: understanding the causes and impact of network failures,? presented at the SIGCOMM '10: Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010. [5] Z. Yin, X. Ma, J. Zheng, Y. Zhou, L. N. Bairavasundaram, and S. Pasupathy, ?An empirical study on configuration errors in commercial and open source systems,? presented at the SOSP '11: Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, 2011. [6] Z. Kerravala, ?As the Value of Enterprise Networks Escalates, So Does the Need for Configuration Management ,? cs.princeton.edu, 01-Jan.-2004. [Online]. Available: https://www.cs.princeton.edu/courses/archive/fall10/cos561/papers/Yankee04.pdf. [Accessed: 09-May-2012]. [7] W. Enck, P. McDaniel, S. Sen, and P. Sebos, ?Configuration management at massive scale: System design and experience,? USENIX '07, Jun. 2007. [8] R. D. Doverspike, K. K. Ramakrishnan, and C. Chase, ?Structural overview of ISP networks,? Guide to Reliable Internet Services and Applications, pp. 19?93, 2010. On 2 August 2012 10:46, George Herbert wrote: > On Wed, Aug 1, 2012 at 5:32 PM, Diogo Montagner > wrote: >> Hi Darius, >> >> You are right. The lost of a customer due to those things. However, I >> would classify this as an unknown situation (in terms of risk >> analisys) because the others I mentioned are possible to calculate and >> estimate (they are known). But it is very hard to estimate if a >> customer will cancel the contract because 1 or n network outages. In >> theory, if the customer SLA is not being met consecutively, there is a >> potential probability he will cancel the contract. >> >> Regards > > On the end customer side, I've done a bunch of reliability / risk cost > assessments for various customers over the years. It's never easy. > > For an ISP... customers are fairly locked in, but for big networks and > customers, especially multihoming customers, business goes where they > want it. > > SLA costs are easy. Predicting the final financial impact is hard. > > > -- > -george william herbert > george.herbert at gmail.com > From kuenzler at init7.net Thu Aug 2 03:33:38 2012 From: kuenzler at init7.net (Fredy Kuenzler) Date: Thu, 02 Aug 2012 10:33:38 +0200 Subject: Level3 (3356/3549) changes routing policy Message-ID: <501A3B62.9020003@init7.net> From my observation Level3 has recently changed their routing policy. It seems that 3356 always prefers customer prefixes of 3549, regardless of the AS path length. Example (seen from 3356): 3549_13030_[Customer1]_[Customer2] is preferred over 2914_[Customer1]_[Customer2] Considering that both 2914 and 3549 are peers of 3356, and 13030 is a customer of 3549, 3356 seems to give higher local-pref on the longer AS-path, likely to increase traffic and revenue of their sister network 3549. Certainly it's common practice to overrule the BGP4 default behaviour, and widely used by smaller networks. Still I'm surprised that it happened obviously rather undetected, at least, to my knowledge, Level3 did implement it silently and hasn't published an official statement or customer announcement, which I think, would have been fair, at least. Considering that Level3 3356 and 3549 are by far the largest networks globally this decision must have a large impact on traffic flows and, of course money flows. Maybe the BGP monitoring experts (aka Renesys et al) can shed some light? -- Fredy K?nzler Init7 / AS13030 From EWieling at nyigc.com Thu Aug 2 06:08:15 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Thu, 2 Aug 2012 07:08:15 -0400 Subject: cost of misconfigurations In-Reply-To: References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: I do not think occasional outages cause significant loss of customers. Customers get angry easily, but once an issue is fixed, they get happy quickly. Customers have very short memories and the cost and hassle of changing services is often significant. Outages are never good, but it is better to concentrate on fixing the issue than panic about customers canceling their service. Many times the cause of an outage is totally out of your control. For example, most of our outages are caused by Verizon's aging and neglected copper cable plant. I often wish some company had the balls to file a class action lawsuit over Verizon's neglect of their copper plant, but NOBODY wants to piss off their ILEC, including us. -----Original Message----- From: Diogo Montagner [mailto:diogo.montagner at gmail.com] Sent: Wednesday, August 01, 2012 8:32 PM To: Darius Jahandarie; Murat Yuksel; nanog at nanog.org Subject: Re: cost of misconfigurations Hi Darius, You are right. The lost of a customer due to those things. However, I would classify this as an unknown situation (in terms of risk analisys) because the others I mentioned are possible to calculate and estimate (they are known). But it is very hard to estimate if a customer will cancel the contract because 1 or n network outages. In theory, if the customer SLA is not being met consecutively, there is a potential probability he will cancel the contract. Regards On 8/2/12, Darius Jahandarie wrote: > On Wed, Aug 1, 2012 at 8:08 PM, Diogo Montagner > wrote: >> A misconfiguration will, at least, impact on two points: network >> outage and re-work. For the network outage, you have to use the SLAs >> to calculate the cost (how much you lost from the customers' revenue) >> due to that outage. On the other hand, there is the time efforts >> spent to fix the misconfiguration. Under the fix, it could be >> removing the misconfig and applying a new one correct. Or just fixing >> the misconfig targeting the correct config. This re-work will >> translate in time, and time can be translated in money spent. > > Isn't the largest cost omitted (or at least glossed over) here? > Namely, lost customers due to the outage. That's why people have SLAs > and rework the network at all -- to avoid that cost. > > > -- > Darius Jahandarie > -- Sent from my mobile device ./diogo -montagner JNCIE-SP 0x41A From david.reader at zeninternet.co.uk Thu Aug 2 07:41:29 2012 From: david.reader at zeninternet.co.uk (David Reader) Date: Thu, 2 Aug 2012 13:41:29 +0100 Subject: Level3 (3356/3549) changes routing policy In-Reply-To: <501A3B62.9020003@init7.net> References: <501A3B62.9020003@init7.net> Message-ID: <20120802134129.f759da0e.david.reader@zeninternet.co.uk> On Thu, 2 Aug 2012 10:33:38 +0200 Fredy Kuenzler wrote: > From my observation Level3 has recently changed their routing policy. It > seems that 3356 always prefers customer prefixes of 3549, regardless of the > AS path length. Example (seen from 3356): > > 3549_13030_[Customer1]_[Customer2] > > is preferred over > > 2914_[Customer1]_[Customer2] > > Considering that both 2914 and 3549 are peers of 3356, and 13030 is a > customer of 3549, 3356 seems to give higher local-pref on the longer > AS-path, likely to increase traffic and revenue of their sister network 3549. Hi Fredy, Level 3 owns both 3356 and 3549. They're simply preferring to have their customers pay them, rather than a 3rd party. I don't think it's suprising at all that they're doing it. If, as you think, it's only happened recently then what is suprising is that it didn't happen sooner IMO. d. From jason at lixfeld.ca Thu Aug 2 08:00:12 2012 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 2 Aug 2012 09:00:12 -0400 Subject: Procera Networks contact Message-ID: If anyone has a contact at Procera Networks who can answer some technical questions about their product, could you please pass it along? The suggested methods at www. have so far gone unanswered. Thanks in advance. From streiner at cluebyfour.org Thu Aug 2 08:38:11 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 2 Aug 2012 09:38:11 -0400 (EDT) Subject: Level3 (3356/3549) changes routing policy In-Reply-To: <20120802134129.f759da0e.david.reader@zeninternet.co.uk> References: <501A3B62.9020003@init7.net> <20120802134129.f759da0e.david.reader@zeninternet.co.uk> Message-ID: On Thu, 2 Aug 2012, David Reader wrote: > On Thu, 2 Aug 2012 10:33:38 +0200 > Level 3 owns both 3356 and 3549. > They're simply preferring to have their customers pay them, rather than > a 3rd party. > > I don't think it's suprising at all that they're doing it. If, as you > think, it's only happened recently then what is suprising is that it > didn't happen sooner IMO. I would also guess that over time, 3549 will go away, as the GX network gets borged into Level3. jms From jvanoppen at spectrumnet.us Thu Aug 2 08:47:52 2012 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 2 Aug 2012 13:47:52 +0000 Subject: Level3 (3356/3549) changes routing policy In-Reply-To: References: <501A3B62.9020003@init7.net> <20120802134129.f759da0e.david.reader@zeninternet.co.uk> Message-ID: It probably should be noted that AS3356's local pref heirarchy is as follows: Highest: customers of 3356 Next highest: customers of 3549 Lowest: peers This does not really seem odd at all, and is probably what I would do if I owned two separate networks that were going to take a long time to merge... We noticed this change at least three months ago so it is not a super recent change. From Dave.Siegel at level3.com Thu Aug 2 08:53:38 2012 From: Dave.Siegel at level3.com (Siegel, David) Date: Thu, 2 Aug 2012 13:53:38 +0000 Subject: Level3 (3356/3549) changes routing policy In-Reply-To: <20120802134129.f759da0e.david.reader@zeninternet.co.uk> References: <501A3B62.9020003@init7.net> <20120802134129.f759da0e.david.reader@zeninternet.co.uk> Message-ID: <72A2F9AF18EC024C962A748EA6CF75B90EC5F17F@W8USSFJ204.ams.gblxint.com> Thanks David, you hit the nail on the head on both points. Level 3 made the routing policy change last November, roughly 6 weeks after the acquisition of Global Crossing. Dave -----Original Message----- From: David Reader [mailto:david.reader at zeninternet.co.uk] Sent: Thursday, August 02, 2012 6:41 AM To: nanog at nanog.org Subject: Re: Level3 (3356/3549) changes routing policy On Thu, 2 Aug 2012 10:33:38 +0200 Fredy Kuenzler wrote: > From my observation Level3 has recently changed their routing policy. > It seems that 3356 always prefers customer prefixes of 3549, > regardless of the AS path length. Example (seen from 3356): > > 3549_13030_[Customer1]_[Customer2] > > is preferred over > > 2914_[Customer1]_[Customer2] > > Considering that both 2914 and 3549 are peers of 3356, and 13030 is a > customer of 3549, 3356 seems to give higher local-pref on the longer > AS-path, likely to increase traffic and revenue of their sister network 3549. Hi Fredy, Level 3 owns both 3356 and 3549. They're simply preferring to have their customers pay them, rather than a 3rd party. I don't think it's suprising at all that they're doing it. If, as you think, it's only happened recently then what is suprising is that it didn't happen sooner IMO. d. From adrian.minta at gmail.com Thu Aug 2 08:55:26 2012 From: adrian.minta at gmail.com (Adrian M) Date: Thu, 2 Aug 2012 16:55:26 +0300 Subject: Level3 (3356/3549) changes routing policy In-Reply-To: <501A3B62.9020003@init7.net> References: <501A3B62.9020003@init7.net> Message-ID: Better to use communities instead. On Aug 2, 2012 11:34 AM, "Fredy Kuenzler" wrote: > From my observation Level3 has recently changed their routing policy. It > seems that 3356 always prefers customer prefixes of 3549, regardless of the > AS path length. Example (seen from 3356): > > 3549_13030_[Customer1]_[**Customer2] > > is preferred over > > 2914_[Customer1]_[Customer2] > > Considering that both 2914 and 3549 are peers of 3356, and 13030 is a > customer of 3549, 3356 seems to give higher local-pref on the longer > AS-path, likely to increase traffic and revenue of their sister network > 3549. > > Certainly it's common practice to overrule the BGP4 default behaviour, and > widely used by smaller networks. > > Still I'm surprised that it happened obviously rather undetected, at > least, to my knowledge, Level3 did implement it silently and hasn't > published an official statement or customer announcement, which I think, > would have been fair, at least. > > Considering that Level3 3356 and 3549 are by far the largest networks > globally this decision must have a large impact on traffic flows and, of > course money flows. > > Maybe the BGP monitoring experts (aka Renesys et al) can shed some light? > > -- > Fredy K?nzler > Init7 / AS13030 > > From ralph.brandt at pateam.com Thu Aug 2 09:31:30 2012 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Thu, 2 Aug 2012 10:31:30 -0400 Subject: cost of misconfigurations In-Reply-To: References: <50196C8E.60100@garlic.com> <5019BA48.1030501@garlic.com> Message-ID: <51C66083768C2949A7EB14910C78B017019A3C04@embgsr24.pateam.com> The misconfiguration cost is usually not calculable in itself. But I think the more important issue is, "How do we prevent it?" I would spend more time on prevention than assessing the cost. I can think of several minor provisioning issues that cost us more in customer relations than everything else put together and a couple significant ones that seemed like nothing happened. And I am not sure I could have predicted the outcome the day before the event if someone had handed me the scenario to assess it. Reason, when it happens the CURRENT situation is as much a driver of the impact as is the actual event. It even goes back to the emotional state of the customer and maybe if his toast was burned this morning, if he/she had a fight with the spouse, who flipped him the bird during his drive in and a lot of other things that dictate mental state. I would be very lax to use a vendor who is taking an approach that all they are concerned about is what an error costs them. I want them to be more concerned about what that costs their customer (me) and what they can do to prevent it. Proper Prior Preparation Prevents Piss Poor Performance. Training, sound processes, good management practices, good maintenance, good personnel selection go a long way. To quote Chief Gassaway (fire chief with good stuff on the web for any business) "Luck validates bad practices." The REB translation, "We did it this way for years and nothing bad happened." In Chief Gassaway's business, bad practices cause Line of Duty Deaths. In ours it causes outages, lost revenue and possibly bankruptcy. Remember, if your company goes belly up, you are out of a job... http://www.samatters.com/2012/07/31/positive-reinforcement-of-undesirabl e-behavior/ Ralph Brandt -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Wednesday, August 01, 2012 9:17 PM To: Diogo Montagner Cc: nanog at nanog.org Subject: Re: cost of misconfigurations On Wed, Aug 1, 2012 at 5:32 PM, Diogo Montagner wrote: > Hi Darius, > > You are right. The lost of a customer due to those things. However, I > would classify this as an unknown situation (in terms of risk > analisys) because the others I mentioned are possible to calculate and > estimate (they are known). But it is very hard to estimate if a > customer will cancel the contract because 1 or n network outages. In > theory, if the customer SLA is not being met consecutively, there is a > potential probability he will cancel the contract. > > Regards On the end customer side, I've done a bunch of reliability / risk cost assessments for various customers over the years. It's never easy. For an ISP... customers are fairly locked in, but for big networks and customers, especially multihoming customers, business goes where they want it. SLA costs are easy. Predicting the final financial impact is hard. -- -george william herbert george.herbert at gmail.com From dot at dotat.at Thu Aug 2 11:04:54 2012 From: dot at dotat.at (Tony Finch) Date: Thu, 2 Aug 2012 17:04:54 +0100 Subject: Is Hotmail in the habit of ignoring MX records? In-Reply-To: References: <20120726071441.GA11199@metron.com> <20120726083535.GA13414@metron.com> <20120727013411.A55B12311FA5@drugs.dv.isc.org> <20120727024538.46BAF23125D1@drugs.dv.isc.org> <20120730170330.C039F23218DD@drugs.dv.isc.org> <30240.1343679970@turing-police.cc.vt.edu> Message-ID: <7774B797-EA29-4E45-BD83-33073D4BF3CA@dotat.at> The relevant spec is RFC 5321 section 5. Tony. -- f.anthony.n.finch http://dotat.at/ On 31 Jul 2012, at 03:27, Jimmy Hess wrote: > > Aside from that RFC974 [Page 3] gives mailers significant leeway in > deciding how to handle errors: From bill at herrin.us Thu Aug 2 11:20:09 2012 From: bill at herrin.us (William Herrin) Date: Thu, 2 Aug 2012 12:20:09 -0400 Subject: Is Hotmail in the habit of ignoring MX records? In-Reply-To: <30240.1343679970@turing-police.cc.vt.edu> References: <20120726071441.GA11199@metron.com> <20120726083535.GA13414@metron.com> <20120727013411.A55B12311FA5@drugs.dv.isc.org> <20120727024538.46BAF23125D1@drugs.dv.isc.org> <20120730170330.C039F23218DD@drugs.dv.isc.org> <30240.1343679970@turing-police.cc.vt.edu> Message-ID: On Mon, Jul 30, 2012 at 4:26 PM, wrote: > On Mon, 30 Jul 2012 10:07:37 -1000, William Herrin said: >> If you can reference where in the SMTP RFC it offers an authoritative >> explanation what to do when merging results from various naming >> systems where one but not all of the naming systems has generated an >> error then let's read it. > > RFC5321, section 5.1 is pretty clear on it: > > 5.1. Locating the Target Host > > Once an SMTP client lexically identifies a domain to which mail will > be delivered for processing (as described in Sections 2.3.5 and 3.6), > a DNS lookup MUST be performed to resolve the domain name (RFC 1035 > [2]). The names are expected to be fully-qualified domain names > (FQDNs): mechanisms for inferring FQDNs from partial names or local > aliases are outside of this specification. Well there you have it. Mechanisms for determining whether a name is intended to be acquired from the DNS are _outside the scope of the RFC_. So, the specifics of merging results from multiple naming systems is left to the implementer without IETF guidance. Clear as mud. And when the RFC goes on to say: > If an empty list of MXs is returned, > the address is treated as if it was associated with an implicit MX > RR, with a preference of 0, pointing to that host. one reasonable interpretation is that MX-type lookups only apply to lookups from the DNS system, another is that both the MX lookup and host lookup have to come from the same naming system, and a third reasonable interpretation is that they do not. And that's true even though the RFC also says: > If a temporary error is returned, the message MUST be queued > and retried later because the MTA *did* successfully acquire the _implicit MX_ from one of the name systems it uses. Chalk this up as a point that "needs work" in the next XX21 RFC. > The Internet uses DNS. You use some other scheme at your own peril, > and probably shouldn't expect said other scheme to work outside the > range of your administrative control. "The Internet" uses a far broader set of technologies than you give it credit for. And it routinely uses the DNS badly. Structure your systems with that understanding or pay for your negligence with malfunction. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From khelms at ispalliance.net Thu Aug 2 11:59:17 2012 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 02 Aug 2012 12:59:17 -0400 Subject: Fwd: Re: DOCSIS 3.0 & PPPoE/L2TP compatibility In-Reply-To: References: <501843BC.5060700@zcorum.com> <5018443C.6010404@ispalliance.net> <50193A65.3090707@northrock.bm> Message-ID: <501AB1E5.4020901@ispalliance.net> Brian, That's only true if you want to truly implement transparent LAN services over DOCSIS. Separating the CPE data flow works with any DOCSIS 1.0 or better modem since all of the tricky parts are in the CMTS. We took a municipal cable network through 3 different CMTSs (3Com and then a Terayon Be2k and finally an Arris C4). The first two did PPPoE hand off to a Redback to act as the LNS and when they wanted to move up to a bigger CMTS the city choose Arris and PPPoE stopped being an option. In short, replacing the modems isn't a requirement unless the modem has to pass up the TLS data, which isn't the case in an open access ISP scenario. On 8/1/2012 3:40 PM, Brian Mengel wrote: > One thing to be mindful of is that BSoD support may not be prevelant > in the installed modem base of your MSO. Replacing those modems would > be costly for someone. > > On Wed, Aug 1, 2012 at 10:17 AM, iptech wrote: >> Hi Scott, >> >> Thanks for the feedback, >> >> yes this is how I understand it also, however I find it strange that the >> Cisco platform designated as the future LNS will not accommodate the DOCSIS >> 3.0requirements - not much collaboration. There is no roadmap for >> introcducing PPTP on the ASR1K that I can see, so i will not be holding out >> for one. >> >> I am veering towards using a L2 pw solution, but would be interested to hear >> what you have used in-house yourself to accommodate this change, care to >> share? >> >> Thanks >> >> >> On 7/31/2012 5:46 PM, Scott Helms wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I've actually run into this specific problem and the issue your running >>> into is that at no time was PPPoE part of the DOCSIS specification. It >>> was supported on several CMTSs because the Cisco UBR shares much of its >>> OS with more mainline Cisco routers which support L2TP and a host of >>> other non-DOCSIS related protocols. It was also widely supported on >>> some of the earliest CMTSs which were bridges instead of routers (then >>> you needed a separate box to be the LNS). The real problem isn't a >>> change in DOCSIS version but that they choose a platform that doesn't >>> share a code base with a general purpose router. This could have been >>> happenstance or by design, but I can tell you your chances of getting >>> PPPoE to work at all on that platform (even for the cable operator) are >>> not high because the box will not operate as a bridge and there is no >>> (AFAIK) way to relay the PPP discover packets. >>> >>> The D3 Arris is either a C4 or a C4C: >>> http://www.arrisi.com/products/product.asp?id=3 >>> >>> On 7/30/2012 8:33 AM, iptech wrote: >>>> Hi, >>>> >>>> We are a small ISP and have a setup in place with the local cable >>>> company for terminating their users via L2TP for Internet access. >>>> However they have just announced to us that they are moving to a >>>> DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE >>>> via L2TP, and can now only offer PPTP for terminating with us. >>>> >>>> We have already begun replacing our Cisco 7206VXR LNS devices with >>>> Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP >>>> and PPTP, whereas the ASR1k can do only L2TP. I do not have any >>>> experience in the cable arena, but from what I have read in the DOCSIS >>>> standards, each version has maintained backwards compatibility, >>>> therefore I am very surprised our CableCo has claimed they cannot do >>>> PPPoE/L2TP anymore. >>>> >>>> The CMTS they are currently using is a Cisco, and now they are moving >>>> to a new ARRIS CMTS. I have not been able to find any information on >>>> this device and what it can do or not. With the ASR1K marked as the >>>> natural upgrade path for LNS functions, therefore I cannot believe >>>> that it is not fully compatible with DOCSIS 3.0. >>>> >>>> From what I can tell the only way to accommodate the new CMTS PPTP >>>> connections will be to terminate them on the legacy 7206VXR, which at >>>> the end of the day is a backwards step. I would greatly appreciate if >>>> anyone can give me any pointers and/or suggestions on this matter, so >>>> I can understand it and move it forward. >>>> >>>> FYI: The driver for the CMTS upgrades is to offer higher bandwidth >>>> access speeds 15mb-20mb. >>>> >>>> Thank you. >>>> >>>> >>>> >>>> >>>> >>> >> -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From rdrake at direcpath.com Thu Aug 2 15:25:56 2012 From: rdrake at direcpath.com (Robert Drake) Date: Thu, 2 Aug 2012 16:25:56 -0400 Subject: Update from the NANOG Communications Committee regarding recent off-topic posts In-Reply-To: <8679FADA-327F-4586-928D-006A054E3686@ianai.net> References: <20120728163636.49bf4f44@segv> <20120730190436.8988.L@m.l.vaunt.eu> <20721.1343669735@turing-police.cc.vt.edu> <8679FADA-327F-4586-928D-006A054E3686@ianai.net> Message-ID: <501AE254.10602@direcpath.com> On 7/30/2012 1:42 PM, Patrick W. Gilmore wrote: > I'm sorry Panashe is upset by this rule. Interestingly, "Your search - Panashe Flack nanog - did not match any documents." So my guess is that a post from that account has not happened before, meaning the post was moderated yet still made it through. > > Has anyone done a data mining experiment to see how many posts a month are from "new" members? My guess is it is a trivial percentage. > Ignoring many harder to determine things like "who has changed their email address" and reducing it to simple shell commands, I got this: for i in `cat ../nanog_archive_index.html | grep txt | cut -f2 -d\"` ; do wget http://mailman.nanog.org/pipermail/nanog/$i; done du -sh=41M (uncompressed=100M). That seems small for all the mail since random 2007 but I'd rather use an official archive so people can duplicate results and refine things. grep -h "^From: " * | sort | uniq -c | sort -nr First of all I will say Owen is winning by a fair margin: 1562 From: owen at delong.com (Owen DeLong) 929 From: randy at psg.com (Randy Bush) 775 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) 688 From: morrowc.lists at gmail.com (Christopher Morrow) 621 From: jbates at brightok.net (Jack Bates) 558 From: jra at baylink.com (Jay Ashworth) 480 From: gbonser at seven.com (George Bonser) 450 From: patrick at ianai.net (Patrick W. Gilmore) 446 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Total count: grep -h "^From: " * | wc -l 54166 # Totals for < 10 contributors for i in 1 2 3 4 5 6 7 8 9; do grep -h "^From: " * | sort | uniq -c | sort -nr | grep " $i" | wc -l; done 3129 1111 552 319 208 157 131 103 94 Total for less than 10 posts contributors: 5804 Percentages: 5804/54166=1% of posts from low contributors. # shows the number of people who've contributed that number of times. grep -h "^From: " * | sort | uniq -c | sort -nr | awk '{print $1}' | uniq -c | sort -nr # another interesting thing to look at is posts by month per user (dropping the -h from grep): grep "^From: " * | sort | uniq -c | sort -nr # not the most efficient, but tells you who posted the most in a month: for i in *; do grep "^From: " * | sort | uniq -c | sort -nr | grep $i | head -n 1; done # Per month, how many single post contributions happen/total. The numbers can be higher here since people who posted in a different month may still be counted as a new contributor for i in *; do echo -n "$i "; grep "^From: " $i | sort | uniq -c | sort -nr | grep " 1 " | wc -l | tr '\n' '/'; grep "^From: " $i | wc -l ; done From valdis.kletnieks at vt.edu Thu Aug 2 15:54:02 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 02 Aug 2012 16:54:02 -0400 Subject: Update from the NANOG Communications Committee regarding recent off-topic posts In-Reply-To: Your message of "Thu, 02 Aug 2012 16:25:56 -0400." <501AE254.10602@direcpath.com> References: <20120728163636.49bf4f44@segv> <20120730190436.8988.L@m.l.vaunt.eu> <20721.1343669735@turing-police.cc.vt.edu> <8679FADA-327F-4586-928D-006A054E3686@ianai.net> <501AE254.10602@direcpath.com> Message-ID: <15020.1343940842@turing-police.cc.vt.edu> On Thu, 02 Aug 2012 16:25:56 -0400, Robert Drake said: > Percentages: 5804/54166=1% of posts from low contributors. I suspect you fat-fingered something - I get 10.7%, not 1%, for that calculation... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jamie at photon.com Thu Aug 2 16:47:43 2012 From: jamie at photon.com (Jamie Bowden) Date: Thu, 2 Aug 2012 21:47:43 +0000 Subject: Update from the NANOG Communications Committee regarding recent off-topic posts In-Reply-To: <15020.1343940842@turing-police.cc.vt.edu> References: <20120728163636.49bf4f44@segv> <20120730190436.8988.L@m.l.vaunt.eu> <20721.1343669735@turing-police.cc.vt.edu> <8679FADA-327F-4586-928D-006A054E3686@ianai.net> <501AE254.10602@direcpath.com> <15020.1343940842@turing-police.cc.vt.edu> Message-ID: <465966A5F5B867419F604CD3E604C1E506087E73@pra-ess-mail.pra.ray.com> What's an order of magnitude between friends? Very occasionally yours, -- Jamie Bowden (jamie at photon.com) Sr. Sys. Admin. (703) 243-6613 x3848 Photon Research Associates, Inc. 1616 Fort Myer Drive, Suite 1000 Arlington, VA 22209 > -----Original Message----- > From: valdis.kletnieks at vt.edu [mailto:valdis.kletnieks at vt.edu] > Sent: Thursday, August 02, 2012 4:56 PM > To: Robert Drake > Cc: nanog at nanog.org > Subject: Re: Update from the NANOG Communications Committee regarding > recent off-topic posts > > On Thu, 02 Aug 2012 16:25:56 -0400, Robert Drake said: > > > Percentages: 5804/54166=1% of posts from low contributors. > > I suspect you fat-fingered something - I get 10.7%, not 1%, for that > calculation... From george.herbert at gmail.com Thu Aug 2 17:01:25 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 2 Aug 2012 15:01:25 -0700 Subject: Update from the NANOG Communications Committee regarding recent off-topic posts In-Reply-To: <465966A5F5B867419F604CD3E604C1E506087E73@pra-ess-mail.pra.ray.com> References: <20120728163636.49bf4f44@segv> <20120730190436.8988.L@m.l.vaunt.eu> <20721.1343669735@turing-police.cc.vt.edu> <8679FADA-327F-4586-928D-006A054E3686@ianai.net> <501AE254.10602@direcpath.com> <15020.1343940842@turing-police.cc.vt.edu> <465966A5F5B867419F604CD3E604C1E506087E73@pra-ess-mail.pra.ray.com> Message-ID: Friends don't let friends binary shift. On Thu, Aug 2, 2012 at 2:47 PM, Jamie Bowden wrote: > What's an order of magnitude between friends? > > Very occasionally yours, > > -- > Jamie Bowden (jamie at photon.com) > Sr. Sys. Admin. (703) 243-6613 x3848 > Photon Research Associates, Inc. > 1616 Fort Myer Drive, Suite 1000 > Arlington, VA 22209 > >> -----Original Message----- >> From: valdis.kletnieks at vt.edu [mailto:valdis.kletnieks at vt.edu] >> Sent: Thursday, August 02, 2012 4:56 PM >> To: Robert Drake >> Cc: nanog at nanog.org >> Subject: Re: Update from the NANOG Communications Committee regarding >> recent off-topic posts >> >> On Thu, 02 Aug 2012 16:25:56 -0400, Robert Drake said: >> >> > Percentages: 5804/54166=1% of posts from low contributors. >> >> I suspect you fat-fingered something - I get 10.7%, not 1%, for that >> calculation... > > -- -george william herbert george.herbert at gmail.com From rhys at rhavenindustrys.com Thu Aug 2 17:22:21 2012 From: rhys at rhavenindustrys.com (Rhys Rhaven) Date: Thu, 02 Aug 2012 17:22:21 -0500 Subject: Update from the NANOG Communications Committee regarding recent off-topic posts In-Reply-To: <5088408F-6BB1-4C5C-9D29-50060ADF3C0C@gmail.com> References: <20120728163636.49bf4f44@segv> <20120730190436.8988.L@m.l.vaunt.eu> <20721.1343669735@turing-police.cc.vt.edu> <8679FADA-327F-4586-928D-006A054E3686@ianai.net> <8929F2FB-6E61-41D9-9C39-621127F2929D@sonn.com> <5016DAB5.6060905@bogus.com> <5088408F-6BB1-4C5C-9D29-50060ADF3C0C@gmail.com> Message-ID: <501AFD9D.2040505@rhavenindustrys.com> On 07/30/2012 09:23 PM, Allen McKinley Kitchen (gmail) wrote: > On Jul 30, 2012, at 15:04, joel jaeggli wrote: > >> On 7/30/12 10:57 AM, Steven Noble wrote: >>> The fix for this issue is trivial. Every new signup ... >> Most of the subscribers to the mailing list never post. >> > +1 (from an inveterate but VERY appreciative lurker) > > ..Allen > I run a tiny network, no AS number. I try to build interesting features into my local hackerspace's network from what I find here. I don't post because I don't have useful experience to the size/scale of what is posted here. I don't know what your organization is really nor where you meet or who any of you are. But even in my small network, I have picked up 10x more operational knowledge here than what I learned from courses and classes, which always seem to push you to use X just because it exists or because its from a specific company. I guess I mean to say thanks, for the knowledge and the moderation. If most are like me, this will make it nicer to read. (except those people whos email client breaks Thunderbird's threading system. no kudos for them.) From aj at jonesy.com.au Thu Aug 2 22:55:21 2012 From: aj at jonesy.com.au (Andrew Jones) Date: Fri, 03 Aug 2012 13:55:21 +1000 Subject: NFSen plugin - ddd Message-ID: <49f9d2ec16de2c67b51a0229dcf18510@localhost> Hi All, Does anyone have a copy of the DDoS detection plugin for NFSen called ddd that they could send to me? According to a blog article [1] I read, it used to be available at [2]. It's not there, and I haven't had any luck trying to track it down the usual ways. If anyone is able to provide a copy, I'd appreciate it. Thanks, Jonesy [1] http://www.ccieflyer.com/2010-01-JasonRowley.php [2] http://www.synacknetworks.com/ddd/ddd.zip From lists at shthead.com Fri Aug 3 02:36:38 2012 From: lists at shthead.com (shthead) Date: Fri, 03 Aug 2012 15:36:38 +0800 Subject: Cisco 7200 PCI Limitations Message-ID: <501B7F86.1090709@shthead.com> Hi all, I have a 7200 series router (7204) here and I am trying to figure out something with it. Currently the router has a NPE-G1 card in it, giving it 3 gig interfaces but I need an extra gig interface on it to make 4. Having a look around the available options are either get a PA-GE card that fits into one of the slots on the router or to get a C7200-I/O-GE+E (I/O controller with a gbit port on it). The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus will limit it to 300mbit full duplex (and it goes on further to say it will be limited to approx 200mbit in best case scenario due to the design of the card) [1]. The other option left is the I/O controller. I found that you can get a port adaptor jacket card [2] for the 7200's that let you stick a normal interface card into the I/O controller slot (instead of the I/O controller itself). My main concern is if the jacket card uses its own PCI bus I am assuming the C7200-I/O-GE+E also connects via PCI which means it would be subject to the same limitations as the PA-GE. Does anyone have any idea if that would be correct and the only option for another gbit port would be to get another device? Thanks for the help [1] http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note09186a00800c814a.shtml#backinfo [2] http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_qas0900aecd8045055e.html From sander at steffann.nl Fri Aug 3 04:44:58 2012 From: sander at steffann.nl (Sander Steffann) Date: Fri, 3 Aug 2012 11:44:58 +0200 Subject: Cisco 7200 PCI Limitations In-Reply-To: <501B7F86.1090709@shthead.com> References: <501B7F86.1090709@shthead.com> Message-ID: <9031D638-EFAA-4563-AC52-424AC7A8C47E@steffann.nl> Hi, > The other option left is the I/O controller. I found that you can get a port adaptor jacket card [2] for the 7200's that let you stick a normal interface card into the I/O controller slot (instead of the I/O controller itself). > > My main concern is if the jacket card uses its own PCI bus I am assuming the C7200-I/O-GE+E also connects via PCI which means it would be subject to the same limitations as the PA-GE. On a 7206VXR it shows: PCI bus mb0_mb1 (Slots 0, 1, 3 and 5) has a capacity of 600 bandwidth points. PCI bus mb2 (Slots 2, 4, 6) has a capacity of 600 bandwidth points. Slot 0 is the I/O module, so it seems to share the same limitations. - Sander From lists at shthead.com Fri Aug 3 04:50:28 2012 From: lists at shthead.com (shthead) Date: Fri, 03 Aug 2012 17:50:28 +0800 Subject: Cisco 7200 PCI Limitations In-Reply-To: <9031D638-EFAA-4563-AC52-424AC7A8C47E@steffann.nl> References: <501B7F86.1090709@shthead.com> <9031D638-EFAA-4563-AC52-424AC7A8C47E@steffann.nl> Message-ID: <501B9EE4.3050602@shthead.com> On 3/08/2012 5:44 PM, Sander Steffann wrote: > On a 7206VXR it shows: > > PCI bus mb0_mb1 (Slots 0, 1, 3 and 5) has a capacity of 600 bandwidth points. > PCI bus mb2 (Slots 2, 4, 6) has a capacity of 600 bandwidth points. > > Slot 0 is the I/O module, so it seems to share the same limitations. > > - Sander > Hi, With the NPE-G1 the I/O controller has its own PCI bus so with that installed it show slike this: PCI bus mb1 (Slots 1, 3 and 5) has a capacity of 600 bandwidth points. Current configuration on bus mb1 has a total of 0 bandwidth points. This configuration is within the PCI bus capacity and is supported. PCI bus mb2 (Slots 2, 4 and 6) has a capacity of 600 bandwidth points. Current configuration on bus mb2 has a total of 400 bandwidth points. This configuration is within the PCI bus capacity and is supported. Thanks for the offlist replies everyone, it looks like the back plane is going to be the limiting factor in this device due to the 1gbps total capacity [1]. [1] http://inetpro.org/wiki/Cisco_7200 From jmaimon at ttec.com Fri Aug 3 08:53:08 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 03 Aug 2012 09:53:08 -0400 Subject: Cisco 7200 PCI Limitations In-Reply-To: <501B7F86.1090709@shthead.com> References: <501B7F86.1090709@shthead.com> Message-ID: <501BD7C4.5050608@ttec.com> shthead wrote: > Hi all, > > I have a 7200 series router (7204) here and I am trying to figure out > something with it. Currently the router has a NPE-G1 card in it, giving > it 3 gig interfaces but I need an extra gig interface on it to make 4. > > Having a look around the available options are either get a PA-GE card > that fits into one of the slots on the router or to get a C7200-I/O-GE+E > (I/O controller with a gbit port on it). I would go with the Gig IO controller. But you are never going to push 4gbit of traffic through this box ever. You probably wont break 500mbps. Or lower, depending on your features. So you might as well use a one or two gig ports trunked to a switch. And if that switch is something like a 3550, then you might have some interesting options. Joe From rmiller at millerad.com Fri Aug 3 09:31:04 2012 From: rmiller at millerad.com (Richard Miller) Date: Fri, 3 Aug 2012 14:31:04 +0000 (UTC) Subject: Verizon FiOS - is BGP an option? References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> Message-ID: This is a fascinating thread! I have had multiple class C address blocks assigned to us for many years (since the 80's) I have 2 T1 connections and one of them is up for contract renewal. I have wanted to replace one of the expensive T1s for a long time. DSL and Cable are available here at reasonable prices (no FIOS yet) However, even after they tell me they will do it, no provider will route even a single /24 (/30) for me. Mostly it's Verizon and/or Time Warner. I would love to have another solution. All I really need is to maintain the IPs on my servers so they are public/world accessible. (Email/Web/FTP/telnet(!)) Perhaps I can route to a co-located server then a tunnel back to the server farm over a static IP DSL or Cable link??? I am stumped. Any ideas? Rich From morrowc.lists at gmail.com Fri Aug 3 09:49:27 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 Aug 2012 10:49:27 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> Message-ID: On Fri, Aug 3, 2012 at 10:31 AM, Richard Miller wrote: > I am stumped. > > Any ideas? time to migrate to carriers that care about you and your business? From cmarlatt at rxsec.com Fri Aug 3 10:22:06 2012 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Fri, 03 Aug 2012 11:22:06 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> Message-ID: <501BEC9E.3030505@rxsec.com> On 08/03/2012 10:31 AM, Richard Miller wrote: <--snip--> > Perhaps I can route to a co-located server then a tunnel back to the server farm > over a static IP DSL or Cable link??? > > I am stumped. > > Any ideas? > > Rich That would indeed be a solution to your problem. Have a "cheap" colo somewhere. Have them advertise your /24's and route them to your server/router and tunnel/vpn the ips back to your location. It's actually pretty simple. Regards, Chris From ahebert at pubnix.net Fri Aug 3 10:26:53 2012 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 03 Aug 2012 11:26:53 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> Message-ID: <501BEDBD.1020503@pubnix.net> Hi, Yes the easier way to do it is have your subnet routed to someone that is willing to colo your router, or provide your with something like NHRP, and use a 87x on your brand new unnamed Cable/DSL provider to create a NHRP tunnel for it. We have many customers which required that kind of tunnel to bypass some belligerent TelCo. But if you're going to drop your T1 for Cable/DSL get 2 of them using different technology and from different provider (aka 1 Cable and 1 DSL =D). Have fun. ----- 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 08/03/12 10:31, Richard Miller wrote: > This is a fascinating thread! > > I have had multiple class C address blocks assigned to us for many years (since > the 80's) I have 2 T1 connections and one of them is up for contract renewal. I > have wanted to replace one of the expensive T1s for a long time. DSL and Cable > are available here at reasonable prices (no FIOS yet) However, even after they > tell me they will do it, no provider will route even a single /24 (/30) for me. > > Mostly it's Verizon and/or Time Warner. > > I would love to have another solution. All I really need is to maintain the IPs > on my servers so they are public/world accessible. (Email/Web/FTP/telnet(!)) > > Perhaps I can route to a co-located server then a tunnel back to the server farm > over a static IP DSL or Cable link??? > > I am stumped. > > Any ideas? > > Rich > > > > > > > > From bill at herrin.us Fri Aug 3 10:56:52 2012 From: bill at herrin.us (William Herrin) Date: Fri, 3 Aug 2012 11:56:52 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <501BEDBD.1020503@pubnix.net> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> Message-ID: On Fri, Aug 3, 2012 at 11:26 AM, Alain Hebert wrote: > Yes the easier way to do it is have your subnet routed to someone that > is willing to colo your router, or provide your with something like NHRP, > and use a 87x on your brand new unnamed Cable/DSL provider to create a NHRP > tunnel for it. > > We have many customers which required that kind of tunnel to bypass some > belligerent TelCo. > > But if you're going to drop your T1 for Cable/DSL get 2 of them using > different technology and from different provider (aka 1 Cable and 1 DSL =D). I'm doing this. Works well most of the time. A couple months ago we had major storm related outages in the area that persisted a couple of days. Internet service on both lines dropped out after 12 hours. It seems the telcos and cable companies don't consider the commodity Internet part of their equipment to be something which needs electricity during an extended grid outage. Cox. Verizon. I'm looking at you. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cmarlatt at rxsec.com Fri Aug 3 11:02:03 2012 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Fri, 03 Aug 2012 12:02:03 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEC9E.3030505@rxsec.com> Message-ID: <501BF5FB.7010306@rxsec.com> On 08/03/2012 11:44 AM, Richard Miller wrote: > Chris, > Been thinking about taking that "route" no pun intended. It just > moves the main link off-site. We've had these T1s for so long the > maintenance and ops have become second nature. Someone should be able to > route over a DSL/Cable/whatever link. Especially if we had a simple > static IP setup. > > the prices are nuts here or T1s. Back in the day I was paying 3000 per > T1..now it's 500/mnth for 1.5 symmetrical. I can get 50/5 or 15/5 from > various providers for around 100/mnth! > > Rich Truth be told you don't even need to pay for a static ip if your termination point supports dynamic clients (i.e. a vpn). It's usually easiest if you have a server as your gateway for the local network too, that'll permit some more granular allowances with the ips, forwarding, etc. OpenVPN is a pretty good daemon for the tunnel. The only thing to keep in mind with the dynamic ips is once in a blue moon (for my area at least) you'll pick up a new ip and have a brief period of packet loss as the vpn re-establishes. Regards, Chris From streiner at cluebyfour.org Fri Aug 3 11:24:28 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 3 Aug 2012 12:24:28 -0400 (EDT) Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> Message-ID: On Fri, 3 Aug 2012, Christopher Morrow wrote: > On Fri, Aug 3, 2012 at 10:31 AM, Richard Miller wrote: >> I am stumped. >> >> Any ideas? > > time to migrate to carriers that care about you and your business? The tough part there is that Verizon is not required (as I understand it) to open access to the plant they've built out for FiOS, unlike their copper plant. That's one of the reasons they've been keen to push people away from DSL and onto FiOS. Short of pulling dark fiber (not cost-effective for hope use yet ;) ) from one of the providers that serves this area, there were no other viable options for getting >T1/DSL speeds to the house :( I ended up having FiOS business service installed about two weeks ago, but it's definitely pricey. jms From patrick at ianai.net Fri Aug 3 13:06:19 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 3 Aug 2012 14:06:19 -0400 Subject: US House to ITU: Hands off the Internet Message-ID: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> [Feels operational to me.] The U.S. House of Representatives voted late Thursday to send a message to the United Nations' International Telecommunication Union that the Internet doesn't need new international regulations. The vote was unanimous: 414-0 Unanimous? I didn't think this congress could agree the earth is round unanimously. -- TTFN, patrick From sethm at rollernet.us Fri Aug 3 13:51:31 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 03 Aug 2012 11:51:31 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> Message-ID: <501C1DB3.7060209@rollernet.us> On 8/3/12 8:56 AM, William Herrin wrote: > On Fri, Aug 3, 2012 at 11:26 AM, Alain Hebert wrote: >> Yes the easier way to do it is have your subnet routed to someone that >> is willing to colo your router, or provide your with something like NHRP, >> and use a 87x on your brand new unnamed Cable/DSL provider to create a NHRP >> tunnel for it. >> >> We have many customers which required that kind of tunnel to bypass some >> belligerent TelCo. >> >> But if you're going to drop your T1 for Cable/DSL get 2 of them using >> different technology and from different provider (aka 1 Cable and 1 DSL =D). > > I'm doing this. Works well most of the time. A couple months ago we > had major storm related outages in the area that persisted a couple of > days. Internet service on both lines dropped out after 12 hours. It > seems the telcos and cable companies don't consider the commodity > Internet part of their equipment to be something which needs > electricity during an extended grid outage. Cox. Verizon. I'm looking > at you. > Most don't, and for the price being paid on commodity connections I feel indifferent about it. The central plant days are mostly gone; there's fiber huts everywhere and not enough trucks/manpower (in my area a lineman sits in his truck and reads a book while tethered to the power kiosk) to run them all if the outage is too widespread for too long. ~Seth From cscora at apnic.net Fri Aug 3 14:15:38 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Aug 2012 05:15:38 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201208031915.q73JFhtZ008888@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 04 Aug, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 421297 Prefixes after maximum aggregation: 176997 Deaggregation factor: 2.38 Unique aggregates announced to Internet: 205030 Total ASes present in the Internet Routing Table: 41696 Prefixes per ASN: 10.10 Origin-only ASes present in the Internet Routing Table: 33409 Origin ASes announcing only one prefix: 15690 Transit ASes present in the Internet Routing Table: 5591 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 32 Max AS path prepend of ASN ( 48687) 24 Prefixes from unregistered ASNs in the Routing Table: 392 Unregistered ASNs in the Routing Table: 151 Number of 32-bit ASNs allocated by the RIRs: 3071 Number of 32-bit ASNs visible in the Routing Table: 2696 Prefixes from 32-bit ASNs in the Routing Table: 6948 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 161 Number of addresses announced to Internet: 2572875148 Equivalent to 153 /8s, 90 /16s and 245 /24s Percentage of available address space announced: 69.4 Percentage of allocated address space announced: 69.5 Percentage of available address space allocated: 99.9 Percentage of address space in use by end-sites: 93.1 Total number of prefixes smaller than registry allocations: 147802 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 102288 Total APNIC prefixes after maximum aggregation: 32823 APNIC Deaggregation factor: 3.12 Prefixes being announced from the APNIC address blocks: 102793 Unique aggregates announced from the APNIC address blocks: 42228 APNIC Region origin ASes present in the Internet Routing Table: 4730 APNIC Prefixes per ASN: 21.73 APNIC Region origin ASes announcing only one prefix: 1240 APNIC Region transit ASes present in the Internet Routing Table: 754 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 271 Number of APNIC addresses announced to Internet: 706547840 Equivalent to 42 /8s, 29 /16s and 16 /24s Percentage of available APNIC address space announced: 82.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 153466 Total ARIN prefixes after maximum aggregation: 77832 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 154514 Unique aggregates announced from the ARIN address blocks: 68935 ARIN Region origin ASes present in the Internet Routing Table: 15204 ARIN Prefixes per ASN: 10.16 ARIN Region origin ASes announcing only one prefix: 5759 ARIN Region transit ASes present in the Internet Routing Table: 1602 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 16 Number of ARIN addresses announced to Internet: 1073191808 Equivalent to 63 /8s, 247 /16s and 155 /24s Percentage of available ARIN address space announced: 56.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 105816 Total RIPE prefixes after maximum aggregation: 55707 RIPE Deaggregation factor: 1.90 Prefixes being announced from the RIPE address blocks: 107992 Unique aggregates announced from the RIPE address blocks: 68316 RIPE Region origin ASes present in the Internet Routing Table: 16728 RIPE Prefixes per ASN: 6.46 RIPE Region origin ASes announcing only one prefix: 8102 RIPE Region transit ASes present in the Internet Routing Table: 2709 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1761 Number of RIPE addresses announced to Internet: 638230756 Equivalent to 38 /8s, 10 /16s and 160 /24s Percentage of available RIPE address space announced: 92.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 43064 Total LACNIC prefixes after maximum aggregation: 8394 LACNIC Deaggregation factor: 5.13 Prefixes being announced from the LACNIC address blocks: 45825 Unique aggregates announced from the LACNIC address blocks: 21998 LACNIC Region origin ASes present in the Internet Routing Table: 1619 LACNIC Prefixes per ASN: 28.30 LACNIC Region origin ASes announcing only one prefix: 421 LACNIC Region transit ASes present in the Internet Routing Table: 314 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 642 Number of LACNIC addresses announced to Internet: 113014696 Equivalent to 6 /8s, 188 /16s and 119 /24s Percentage of available LACNIC address space announced: 67.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9558 Total AfriNIC prefixes after maximum aggregation: 2187 AfriNIC Deaggregation factor: 4.37 Prefixes being announced from the AfriNIC address blocks: 10012 Unique aggregates announced from the AfriNIC address blocks: 3413 AfriNIC Region origin ASes present in the Internet Routing Table: 553 AfriNIC Prefixes per ASN: 18.10 AfriNIC Region origin ASes announcing only one prefix: 168 AfriNIC Region transit ASes present in the Internet Routing Table: 124 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 41555712 Equivalent to 2 /8s, 122 /16s and 23 /24s Percentage of available AfriNIC address space announced: 41.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2760 11123 1253 Korea Telecom (KIX) 17974 2291 702 54 PT TELEKOMUNIKASI INDONESIA 7545 1710 301 86 TPG Internet Pty Ltd 4755 1603 386 156 TATA Communications formerly 9829 1310 1084 31 BSNL National Internet Backbo 9583 1159 87 507 Sify Limited 7552 1128 1062 11 Vietel Corporation 4808 1122 2052 322 CNCGROUP IP network: China169 24560 1037 384 165 Bharti Airtel Ltd., Telemedia 9498 993 294 73 BHARTI Airtel Ltd. 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 7029 3443 986 155 Windstream Communications Inc 6389 3343 3773 191 bellsouth.net, inc. 18566 2088 382 181 Covad Communications 1785 1946 681 131 PaeTec Communications, Inc. 22773 1699 2914 125 Cox Communications, Inc. 20115 1646 1572 611 Charter Communications 4323 1577 1027 385 Time Warner Telecom 30036 1431 280 786 Mediacom Communications Corp 7018 1247 10039 816 AT&T WorldNet Services 11492 1191 216 351 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1569 544 16 Corbina telecom 15557 1215 2247 55 LDCOM NETWORKS 12479 823 761 88 Uni2 Autonomous System 34984 735 189 177 BILISIM TELEKOM 20940 722 236 566 Akamai Technologies European 6830 714 2310 445 UPC Distribution Services 31148 704 37 9 FreeNet ISP 2118 664 97 14 EUnet/RELCOM Autonomous Syste 13188 660 100 9 Educational Network 8551 577 364 61 Bezeq International 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 2036 350 211 TVCABLE BOGOTA 28573 2026 1228 58 NET Servicos de Comunicao S.A 6503 1527 419 66 AVANTEL, S.A. 8151 1473 3071 346 UniNet S.A. de C.V. 7303 1460 936 198 Telecom Argentina Stet-France 6458 882 81 15 GUATEL 27947 719 74 95 Telconet S.A 11172 644 91 74 Servicios Alestra S.A de C.V 3816 602 255 90 Empresa Nacional de Telecomun 22047 583 326 15 VTR PUNTO NET S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 966 958 13 TEDATA 24863 864 274 32 LINKdotNET AS number 6713 509 650 19 Itissalat Al-MAGHRIB 36998 483 48 3 MOBITEL 24835 286 80 8 RAYA Telecom - Egypt 3741 262 905 223 The Internet Solution 33776 228 12 19 Starcomms Nigeria Limited 12258 197 28 62 Vodacom Internet Company 29975 191 667 21 Vodacom 15706 177 32 6 Sudatel Internet Exchange Aut 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 7029 3443 986 155 Windstream Communications Inc 6389 3343 3773 191 bellsouth.net, inc. 4766 2760 11123 1253 Korea Telecom (KIX) 17974 2291 702 54 PT TELEKOMUNIKASI INDONESIA 18566 2088 382 181 Covad Communications 10620 2036 350 211 TVCABLE BOGOTA 28573 2026 1228 58 NET Servicos de Comunicao S.A 1785 1946 681 131 PaeTec Communications, Inc. 7545 1710 301 86 TPG Internet Pty Ltd 22773 1699 2914 125 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3343 3152 bellsouth.net, inc. 17974 2291 2237 PT TELEKOMUNIKASI INDONESIA 28573 2026 1968 NET Servicos de Comunicao S.A 18566 2088 1907 Covad Communications 10620 2036 1825 TVCABLE BOGOTA 1785 1946 1815 PaeTec Communications, Inc. 7545 1710 1624 TPG Internet Pty Ltd 22773 1699 1574 Cox Communications, Inc. 8402 1569 1553 Corbina telecom 4766 2760 1507 Korea Telecom (KIX) Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.65.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.67.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.68.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.71.0/24 35567 DASTO semtel d.o.o. 59458 UNALLOCATED 5.149.96.0/21 50597 ScopeSky Communicati 59458 UNALLOCATED 5.149.104.0/22 50597 ScopeSky Communicati 59473 UNALLOCATED 5.149.152.0/22 44843 AmsterdamTelecom Ltd Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.175.80.0/21 47886 Equinix Netherlands IP Platfo 5.175.128.0/17 12586 GHOSTnet 5.178.24.0/21 21191 SeverTransTeleCom Autonomous 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 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:19 /9:12 /10:28 /11:82 /12:236 /13:474 /14:848 /15:1529 /16:12336 /17:6372 /18:10753 /19:20953 /20:29981 /21:31860 /22:41601 /23:39706 /24:220602 /25:1282 /26:1504 /27:852 /28:164 /29:61 /30:18 /31:0 /32:24 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2802 3443 Windstream Communications Inc 18566 2038 2088 Covad Communications 6389 1835 3343 bellsouth.net, inc. 30036 1366 1431 Mediacom Communications Corp 8402 1266 1569 Corbina telecom 15557 1159 1215 LDCOM NETWORKS 11492 1154 1191 Cable One 22773 1123 1699 Cox Communications, Inc. 1785 1053 1946 PaeTec Communications, Inc. 6503 1050 1527 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:558 2:704 3:1 4:13 5:299 6:3 8:439 12:2003 13:1 14:632 15:11 16:3 17:6 20:24 23:204 24:1800 27:1327 31:1024 32:56 33:2 34:2 36:8 37:664 38:821 39:1 40:134 41:2838 42:158 44:3 46:1554 47:2 49:427 50:576 52:13 54:14 55:8 56:1 57:31 58:986 59:510 60:236 61:1284 62:974 63:2028 64:4246 65:2250 66:4532 67:2037 68:1152 69:3204 70:986 71:520 72:1867 74:2608 75:489 76:332 77:951 78:946 79:497 80:1275 81:945 82:640 83:541 84:619 85:1147 86:797 87:932 88:353 89:1794 90:305 91:5067 92:588 93:1452 94:1557 95:1278 96:400 97:318 98:903 99:39 100:22 101:257 103:1341 105:464 106:112 107:189 108:413 109:1911 110:795 111:947 112:434 113:676 114:687 115:858 116:930 117:735 118:944 119:1236 120:360 121:696 122:1677 123:1162 124:1378 125:1265 128:555 129:183 130:267 131:640 132:297 133:22 134:245 135:61 136:216 137:240 138:342 139:183 140:496 141:258 142:451 143:374 144:496 145:78 146:510 147:290 148:770 149:319 150:150 151:186 152:473 153:175 154:19 155:405 156:222 157:381 158:191 159:630 160:348 161:386 162:385 163:190 164:675 165:411 166:577 167:533 168:963 169:126 170:899 171:147 172:5 173:1739 174:628 175:432 176:570 177:1003 178:1657 180:1327 181:115 182:1030 183:233 184:572 186:2069 187:1115 188:1338 189:1588 190:6176 192:6026 193:5444 194:4198 195:3264 196:1231 197:201 198:3695 199:4945 200:6015 201:1981 202:8728 203:8694 204:4393 205:2534 206:2796 207:2861 208:4042 209:3631 210:2761 211:1548 212:2010 213:1808 214:878 215:86 216:5083 217:1555 218:561 219:315 220:1239 221:570 222:336 223:372 End of report From otis at ocosa.com Fri Aug 3 14:22:59 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Fri, 3 Aug 2012 14:22:59 -0500 Subject: IPv6 End User Fee Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Anyone charging end users for IPv6 space yet? :p Just wondering, with so many IPv6 resources in a single allocation it would seem difficult to charge anything at all. 1. How are you making up loss of revenue on IPv4 assignments? 2. Are you charging anything? 3. Is the cost built into the service? 4. Do you assign IPv6 space to end user and charge admin fee? Take care, Otis From bill at herrin.us Fri Aug 3 14:31:22 2012 From: bill at herrin.us (William Herrin) Date: Fri, 3 Aug 2012 09:31:22 -1000 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <501C1DB3.7060209@rollernet.us> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> Message-ID: On Fri, Aug 3, 2012 at 8:51 AM, Seth Mattinen wrote: > On 8/3/12 8:56 AM, William Herrin wrote: >> It >> seems the telcos and cable companies don't consider the commodity >> Internet part of their equipment to be something which needs >> electricity during an extended grid outage. Cox. Verizon. I'm looking >> at you. > > Most don't, and for the price being paid on commodity connections I feel > indifferent about it. Back in the day they kept my land line phone on during extended power outages. And that was when they had to power the phone. Now all they have to do is power the equipment on their end of the line. My phone's out because hey, voip. My Sprint cell phone's out because the fools can't power their towers. It's 105 degrees out and I'm screwed if someone has a heat stroke because we can't even call 911. > The central plant days are mostly gone; there's > fiber huts everywhere and not enough trucks/manpower (in my area a > lineman sits in his truck and reads a book while tethered to the power > kiosk) to run them all if the outage is too widespread for too long. They put a quarter million dollars into the fiber hut. They can't put a $500 gasoline generator in a warehouse 50 miles away and go pick it up when there's an extended outage? I'll give Verizon a little credit. They restored service after about 12 hours of outage. Cox didn't restore service until 12 hours *after* my power came back on. Could be worse. I could have Pepco instead of Dominion. But it could be better. And 20 years ago the reliability was. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Fri Aug 3 14:38:07 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 03 Aug 2012 12:38:07 -0700 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: <501C289F.2070703@rollernet.us> On 8/3/12 12:22 PM, Otis L. Surratt, Jr. wrote: > Anyone charging end users for IPv6 space yet? :p > Nope, and no plans to. ~Seth From trejrco at gmail.com Fri Aug 3 14:37:45 2012 From: trejrco at gmail.com (TJ) Date: Fri, 3 Aug 2012 15:37:45 -0400 Subject: IPv6 End User Fee In-Reply-To: <501C289F.2070703@rollernet.us> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <501C289F.2070703@rollernet.us> Message-ID: FWIW - Comcast isn't charging for native connectivity to residential users. /TJ On Fri, Aug 3, 2012 at 3:38 PM, Seth Mattinen wrote: > On 8/3/12 12:22 PM, Otis L. Surratt, Jr. wrote: > > Anyone charging end users for IPv6 space yet? :p > > > > Nope, and no plans to. > > ~Seth > > From owen at delong.com Fri Aug 3 15:01:35 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Aug 2012 13:01:35 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> Message-ID: On Aug 3, 2012, at 12:31 , William Herrin wrote: > On Fri, Aug 3, 2012 at 8:51 AM, Seth Mattinen wrote: >> On 8/3/12 8:56 AM, William Herrin wrote: >>> It >>> seems the telcos and cable companies don't consider the commodity >>> Internet part of their equipment to be something which needs >>> electricity during an extended grid outage. Cox. Verizon. I'm looking >>> at you. >> >> Most don't, and for the price being paid on commodity connections I feel >> indifferent about it. > > Back in the day they kept my land line phone on during extended power > outages. And that was when they had to power the phone. Now all they > have to do is power the equipment on their end of the line. My phone's > out because hey, voip. My Sprint cell phone's out because the fools > can't power their towers. It's 105 degrees out and I'm screwed if > someone has a heat stroke because we can't even call 911. > 48vDC battery to power your phone up to 3 ringer equivalences was a pretty light load overall, compared to PON aggregators for all those neighborhoods. Further, as noted above the PON equipment is much more widely distributed than powering your phone. Powering your phone was straight DC down the same copper wire as your service. Powering the PON aggregators, well, unless you've got some magic new technology for powering them via fiber is a bit more involved and quite a bit more amperage per conductor than POTS. > >> The central plant days are mostly gone; there's >> fiber huts everywhere and not enough trucks/manpower (in my area a >> lineman sits in his truck and reads a book while tethered to the power >> kiosk) to run them all if the outage is too widespread for too long. > > They put a quarter million dollars into the fiber hut. They can't put > a $500 gasoline generator in a warehouse 50 miles away and go pick it > up when there's an extended outage? That's a lot of generators and a lot of people to go pull them out and make sure they don't walk off during said extended outage. > I'll give Verizon a little credit. They restored service after about > 12 hours of outage. Cox didn't restore service until 12 hours *after* > my power came back on. > Seems pretty reasonable to me given the scale of the outage. > Could be worse. I could have Pepco instead of Dominion. But it could > be better. And 20 years ago the reliability was. 20 years ago you didn't have a megabit to your home let alone many megabits. 20 years ago, POTS was much simpler than the converged networks we have today. There is something to be said for the simplicity of POTS. If you're that concerned about calling 911 for a heat stroke, why don't you maintain a POTS line? Owen From efinley.lists at gmail.com Fri Aug 3 15:19:18 2012 From: efinley.lists at gmail.com (Elliot Finley) Date: Fri, 3 Aug 2012 14:19:18 -0600 Subject: Looking for MX clue at cable.comcast.net Message-ID: When I try to us the automated form to unblock my server's IP I get: ******* 67.22.175.244 We have received your request for removal from our inbound blocklist. After investigating the issue, we have found that the IP you provided for removal is currently not on our blocklist. We need the IP address currently blocked to further investigate this issue. The IP address is a number separated by decimals and is located in an error code starting with "550" in the returned email from Comcast. Please verify the IP(s) and resubmit your request to http://postmaster.comcast.net ******* and yet I consistently get: Remote host said: 554 Transaction Failed Spam Message not queued. when trying to send any email from the above mentioned IP. Please contact me via efinley at emerytelcom.com (from a non comcast address so I can email you back) or directly @ 435.636.0069 Thanks, Elliot From jcurran at arin.net Fri Aug 3 15:47:30 2012 From: jcurran at arin.net (John Curran) Date: Fri, 3 Aug 2012 20:47:30 +0000 Subject: US House to ITU: Hands off the Internet In-Reply-To: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> Message-ID: <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> On Aug 3, 2012, at 2:06 PM, "Patrick W. Gilmore" wrote: > [Feels operational to me.] > > > > The U.S. House of Representatives voted late Thursday to send a message to the United Nations' International Telecommunication Union that the Internet doesn't need new international regulations. The vote was unanimous: 414-0 > > Unanimous? I didn't think this congress could agree the earth is round unanimously. It is can be useful (particularly during an election year) to make certain that there is no doubt regarding the resolve of government with respect to positions being taken in international negotiations. In this case, I believe that the message is now quite clear... :-) /John John Curran President and CEO ARIN From james.cutler at consultant.com Fri Aug 3 15:48:51 2012 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 3 Aug 2012 16:48:51 -0400 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: On Aug 3, 2012, at 3:22 PM, "Otis L. Surratt, Jr." wrote: > Anyone charging end users for IPv6 space yet? :p > > > Otis > I can't imagine that this would be anything but counterproductive. End users are not interested in IPv6 - most would not recognize IPv6 if it fell out of their screen. End users want working connectivity, not jargon. James R. Cutler james.cutler at consultant.com From surfer at mauigateway.com Fri Aug 3 16:02:56 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 3 Aug 2012 14:02:56 -0700 Subject: US House to ITU: Hands off the Internet Message-ID: <20120803140256.A244B773@resin03.mta.everyone.net> ------------------------ > The U.S. House of Representatives voted late Thursday to send a message to the United Nations' International Telecommunication Union that the Internet doesn't need new international regulations. The vote was unanimous: 414-0 > > Unanimous? I didn't think this congress could agree the earth is round unanimously. ------------------------------ Have you *ever* seen control frea...err...governments vote to relinquish their power to other governments? ;-) scott From bmanning at vacation.karoshi.com Fri Aug 3 16:09:30 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 3 Aug 2012 21:09:30 +0000 Subject: US House to ITU: Hands off the Internet In-Reply-To: <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> Message-ID: <20120803210930.GA27654@vacation.karoshi.com.> On Fri, Aug 03, 2012 at 08:47:30PM +0000, John Curran wrote: > On Aug 3, 2012, at 2:06 PM, "Patrick W. Gilmore" wrote: > > > [Feels operational to me.] > > > > > > > > The U.S. House of Representatives voted late Thursday to send a message to the United Nations' International Telecommunication Union that the Internet doesn't need new international regulations. The vote was unanimous: 414-0 > > > > Unanimous? I didn't think this congress could agree the earth is round unanimously. > > It is can be useful (particularly during an election year) to make > certain that there is no doubt regarding the resolve of government > with respect to positions being taken in international negotiations. > > In this case, I believe that the message is now quite clear... > > :-) > /John > > John Curran > President and CEO > ARIN Its just the house.... :) But I suspect Terry & delegation will take note. /bill From bill at herrin.us Fri Aug 3 16:17:58 2012 From: bill at herrin.us (William Herrin) Date: Fri, 3 Aug 2012 11:17:58 -1000 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> Message-ID: On Fri, Aug 3, 2012 at 10:01 AM, Owen DeLong wrote: > On Aug 3, 2012, at 12:31 , William Herrin wrote: >> Could be worse. I could have Pepco instead of Dominion. But it could >> be better. And 20 years ago the reliability was. > > 20 years ago you didn't have a megabit to your home let alone many > megabits. 20 years ago, POTS was much simpler than the converged > networks we have today. There is something to be said for the simplicity > of POTS. > > If you're that concerned about calling 911 for a heat stroke, why don't > you maintain a POTS line? When Verizon installed FIOS in the neighborhood they removed the copper lines to each house. It was understood and accepted that if the household fiber adapters did not receive power the battery would fail in a few hours. That the upstream would fail, even for folks who took measures to continue to power the fiber adapter, was unexpected and very unfortunate. If they can run a copper pair back to a powerable location then it escapes me why they can't do the same with a single strand of fiber. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From efinley.lists at gmail.com Fri Aug 3 16:19:14 2012 From: efinley.lists at gmail.com (Elliot Finley) Date: Fri, 3 Aug 2012 15:19:14 -0600 Subject: Looking for MX clue at cable.comcast.net In-Reply-To: References: Message-ID: Correction: It's cable.comcast.com (not .net) and it turns out that that is the domain used by comcast employees not customers. our mail gets delivered to comcast customers just fine, just not to comcast employees. I have to say that the tier 1 person I talked to was fairly clueful regarding possible issues delivering to comcast customers, but she didn't have any knowledge about the employee domain. If postmaster at cable.comcast.com sees this, please give me a call: 435.636.0069. I'd like to get this resolved ASAP. Thanks, Elliot On Fri, Aug 3, 2012 at 2:19 PM, Elliot Finley wrote: > When I try to us the automated form to unblock my server's IP I get: > > ******* > 67.22.175.244 > We have received your request for removal from our inbound blocklist. > After investigating the issue, we have found that the IP you provided > for removal is currently not on our blocklist. > > We need the IP address currently blocked to further investigate this > issue. The IP address is a number separated by decimals and is located > in an error code starting with "550" in the returned email from > Comcast. > Please verify the IP(s) and resubmit your request to > http://postmaster.comcast.net > ******* > > and yet I consistently get: > > Remote host said: 554 Transaction Failed Spam Message not queued. > > when trying to send any email from the above mentioned IP. > > Please contact me via efinley at emerytelcom.com (from a non comcast > address so I can email you back) > or directly @ 435.636.0069 > > Thanks, > Elliot From gary.buhrmaster at gmail.com Fri Aug 3 16:24:43 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 3 Aug 2012 21:24:43 +0000 Subject: US House to ITU: Hands off the Internet In-Reply-To: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> Message-ID: On Fri, Aug 3, 2012 at 6:06 PM, Patrick W. Gilmore wrote: .... > Unanimous? I didn't think this congress could agree the earth is round unanimously. Perhaps because the earth is usually more properly described as an oblate spheroid... Gary From frnkblk at iname.com Fri Aug 3 16:26:56 2012 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 3 Aug 2012 16:26:56 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> Message-ID: <00cd01cd71be$b56718d0$20354a70$@iname.com> A good portable generator is more than $500, and if it's a wide-spread outage there's not enough portable generators to go around, and if there were, not enough people to set them and give them their fluids. And it doesn't pay to put a natural gas (or similar) generator at every node for those rare instances where the battery does not suffice. Frank -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Friday, August 03, 2012 2:31 PM To: Seth Mattinen Cc: nanog at nanog.org Subject: Re: Verizon FiOS - is BGP an option? On Fri, Aug 3, 2012 at 8:51 AM, Seth Mattinen wrote: > The central plant days are mostly gone; there's > fiber huts everywhere and not enough trucks/manpower (in my area a > lineman sits in his truck and reads a book while tethered to the power > kiosk) to run them all if the outage is too widespread for too long. They put a quarter million dollars into the fiber hut. They can't put a $500 gasoline generator in a warehouse 50 miles away and go pick it up when there's an extended outage? I'll give Verizon a little credit. They restored service after about 12 hours of outage. Cox didn't restore service until 12 hours *after* my power came back on. Could be worse. I could have Pepco instead of Dominion. But it could be better. And 20 years ago the reliability was. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Fri Aug 3 16:37:23 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 Aug 2012 17:37:23 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> Message-ID: On Fri, Aug 3, 2012 at 5:17 PM, William Herrin wrote: > On Fri, Aug 3, 2012 at 10:01 AM, Owen DeLong wrote: >> On Aug 3, 2012, at 12:31 , William Herrin wrote: >>> Could be worse. I could have Pepco instead of Dominion. But it could >>> be better. And 20 years ago the reliability was. >> >> 20 years ago you didn't have a megabit to your home let alone many >> megabits. 20 years ago, POTS was much simpler than the converged >> networks we have today. There is something to be said for the simplicity >> of POTS. >> >> If you're that concerned about calling 911 for a heat stroke, why don't >> you maintain a POTS line? > > When Verizon installed FIOS in the neighborhood they removed the > copper lines to each house. It was understood and accepted that if the ACTUALLY... no. they are NOT supposed to do this, in fact they said to congress that they were NOT removing copper, not clipping it outside the prem (despite what I've seen with my own eyes...). I think it's actually a violation for them to clip the copper, and to not support it, since it was put in with public funds... but ianal and all that patrick stuff. > household fiber adapters did not receive power the battery would fail > in a few hours. That the upstream would fail, even for folks who took > measures to continue to power the fiber adapter, was unexpected and > very unfortunate. If they can run a copper pair back to a powerable > location then it escapes me why they can't do the same with a single > strand of fiber. they do not want to be beholden to the PUC if they can avoid it... > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From bill at herrin.us Fri Aug 3 16:52:53 2012 From: bill at herrin.us (William Herrin) Date: Fri, 3 Aug 2012 11:52:53 -1000 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <00cd01cd71be$b56718d0$20354a70$@iname.com> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> Message-ID: On Fri, Aug 3, 2012 at 11:26 AM, Frank Bulk wrote: > A good portable generator is more than $500, and if it's a wide-spread > outage there's not enough portable generators to go around, and if there > were, not enough people to set them and give them their fluids. Doesn't take a "good" generator to maintain a -48V battery string. Drop it off. Plug it in. Start it up. Task some folks on an 8 hour loop to keep the tanks topped off. If the DOT, not noted for its efficiency, can get the major traffic lights up and running on generators the next day, why can't Sprint, Cox and Verizon get their towers and fiber concentrators powered up? That's a condemnation worthy of the word: that your company performed worse in the storm recovery than the local department of transportation. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Fri Aug 3 16:53:47 2012 From: jcurran at arin.net (John Curran) Date: Fri, 3 Aug 2012 21:53:47 +0000 Subject: US House to ITU: Hands off the Internet In-Reply-To: <20120803210930.GA27654@vacation.karoshi.com> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> <20120803210930.GA27654@vacation.karoshi.com> Message-ID: <8465042D-8361-4726-867E-608B393F5226@corp.arin.net> On Aug 3, 2012, at 5:09 PM, bmanning at vacation.karoshi.com wrote: > On Fri, Aug 03, 2012 at 08:47:30PM +0000, John Curran wrote: >> In this case, I believe that the message is now quite clear... > > Its just the house.... :) But I suspect Terry & delegation will take note. Actually, I believe that the message originated with the Administration (i.e. NTIA, State ala Ambr Verveer and Ambr Kramer, and WH/OSTP) and we are seeing the endorsement by the House of that proposed approach. (For specific details, I would refer to Ambr Kramers remarks from earlier this week at the ITIC ) FYi, /John John Curran President and CEO ARIN From kwallace at pcconnection.com Fri Aug 3 16:56:37 2012 From: kwallace at pcconnection.com (Wallace Keith) Date: Fri, 3 Aug 2012 17:56:37 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <00cd01cd71be$b56718d0$20354a70$@iname.com> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> Message-ID: -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Friday, August 03, 2012 5:27 PM To: 'William Herrin' Cc: nanog at nanog.org Subject: RE: Verizon FiOS - is BGP an option? A good portable generator is more than $500, and if it's a wide-spread outage there's not enough portable generators to go around, and if there were, not enough people to set them and give them their fluids. And it doesn't pay to put a natural gas (or similar) generator at every node for those rare instances where the battery does not suffice. Frank -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Friday, August 03, 2012 2:31 PM To: Seth Mattinen Cc: nanog at nanog.org Subject: Re: Verizon FiOS - is BGP an option? On Fri, Aug 3, 2012 at 8:51 AM, Seth Mattinen wrote: > The central plant days are mostly gone; there's fiber huts everywhere > and not enough trucks/manpower (in my area a lineman sits in his truck > and reads a book while tethered to the power > kiosk) to run them all if the outage is too widespread for too long. They put a quarter million dollars into the fiber hut. They can't put a $500 gasoline generator in a warehouse 50 miles away and go pick it up when there's an extended outage? I'll give Verizon a little credit. They restored service after about 12 hours of outage. Cox didn't restore service until 12 hours *after* my power came back on. Could be worse. I could have Pepco instead of Dominion. But it could be better. And 20 years ago the reliability was. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 One would think the head end of the fiber would have batteries and a generator. I have TDS fiber at home and I believe it goes all the way back to the CO with no active items between. I do have UPS's and a genset to keep the ONT and servers running. Here in Fairpoint (former Verizon) land, most of the SLC huts I've seen, have either a genset or a plug for a mobile generator on the side of the bldg. The generators in the service vehicles can plug into these. The cable (HFC) infrastructure, on the other hand, has pole mounted power supplies that apparently (to me) go dead within an hour of a power failure. No way to back them up easily that I can see. Running BGP and hosting over a residential service such as cable or DSL, has it's limitations as I have learned. I doubt your LEC has an SLA for DSL service. I would look at hosting somewhere closer to your eyeball networks and let them worry about power, cooling and network availability. -Keith From dburk at burkov.aha.ru Fri Aug 3 16:57:24 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sat, 4 Aug 2012 01:57:24 +0400 Subject: US House to ITU: Hands off the Internet In-Reply-To: <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> Message-ID: <4873D44B-A5C3-4C28-B00A-7E02C4AB4E23@burkov.aha.ru> John, I like your approach - simply no comments I think the way as your legislation guys decided to follow can be absolutely wrong. My opinion that the real problem laid in financial issues with developing countires and US native commercial interests that you (not you personally - of course) aimed to protect All this discussion have only financial background - no more. Dima PS You can reference not only to magazines - but more on House of Representatives which expressed their opinions more openly. On Aug 4, 2012, at 12:47 AM, John Curran wrote: > On Aug 3, 2012, at 2:06 PM, "Patrick W. Gilmore" wrote: > >> [Feels operational to me.] >> >> >> >> The U.S. House of Representatives voted late Thursday to send a message to the United Nations' International Telecommunication Union that the Internet doesn't need new international regulations. The vote was unanimous: 414-0 >> >> Unanimous? I didn't think this congress could agree the earth is round unanimously. > > It is can be useful (particularly during an election year) to make > certain that there is no doubt regarding the resolve of government > with respect to positions being taken in international negotiations. > > In this case, I believe that the message is now quite clear... > > :-) > /John > > John Curran > President and CEO > ARIN > > > > From cidr-report at potaroo.net Fri Aug 3 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Aug 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201208032200.q73M00Bp042688@wattle.apnic.net> This report has been generated at Fri Aug 3 21:13:03 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 27-07-12 421258 243452 28-07-12 421509 243642 29-07-12 421732 243605 30-07-12 421263 243951 31-07-12 421699 244653 01-08-12 423193 244312 02-08-12 423313 244418 03-08-12 423749 244407 AS Summary 41805 Number of ASes in routing system 17447 Number of ASes announcing only one prefix 3444 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 114212832 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 03Aug12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 423734 244478 179256 42.3% All ASes AS6389 3343 194 3149 94.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2026 63 1963 96.9% NET Servicos de Comunicao S.A. AS17974 2291 437 1854 80.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3444 1772 1672 48.5% WINDSTREAM - Windstream Communications Inc AS18566 2088 417 1671 80.0% COVAD - Covad Communications Co. AS4766 2765 1296 1469 53.1% KIXS-AS-KR Korea Telecom AS10620 2036 608 1428 70.1% Telmex Colombia S.A. AS4323 1580 389 1191 75.4% TWTC - tw telecom holdings, inc. AS1785 1947 818 1129 58.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 1699 576 1123 66.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1604 541 1063 66.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1459 445 1014 69.5% Telecom Argentina S.A. AS7552 1128 227 901 79.9% VIETEL-AS-AP Vietel Corporation AS6458 881 48 833 94.6% Telgua AS8151 1475 669 806 54.6% Uninet S.A. de C.V. AS18101 941 158 783 83.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1122 355 767 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 910 167 743 81.6% CRNET CHINA RAILWAY Internet(CRNET) AS13977 839 123 716 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS15557 1215 552 663 54.6% LDCOMNET Societe Francaise du Radiotelephone S.A AS2118 664 14 650 97.9% RELCOM-AS OOO "NPO Relcom" AS855 684 52 632 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1106 474 632 57.1% LEVEL3 Level 3 Communications AS17676 699 75 624 89.3% GIGAINFRA Softbank BB Corp. AS22561 1025 414 611 59.6% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1001 403 598 59.7% VZGNI-TRANSIT - Verizon Online LLC AS24560 1038 449 589 56.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4780 812 242 570 70.2% SEEDNET Digital United Inc. AS30036 1432 868 564 39.4% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS3549 998 437 561 56.2% GBLX Global Crossing Ltd. Total 44252 13283 30969 70.0% Top 30 total Possible Bogus Routes 5.178.24.0/21 AS21191 ASN-SEVERTTK Closed Joint Stock Company "SeverTransTeleCom" 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.207.224.0/23 AS36898 UNINET AfricaINX created auth-num for AS36898 41.207.238.0/23 AS36898 UNINET AfricaINX created auth-num for AS36898 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.112.96.0/22 AS2828 XO-AS15 - XO Communications 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.14.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.15.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 172.120.16.0/21 AS19891 BML-AS Bill Me Later, Inc 192.0.0.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.18.0.0/15 AS14744 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.51.100.0/24 AS14744 INTERNAP-BLOCK-4 - Internap Network Services Corporation 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.24.73.0/24 AS26061 Equant Colombia 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/21 AS14754 Telgua 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.180.224.0/19 AS1221 ASN-TELSTRA Telstra Pty Ltd 202.180.236.0/24 AS38472 UCMS-AS-AP UCMS 202.180.253.0/24 AS38472 UCMS-AS-AP UCMS 202.180.255.0/24 AS38472 UCMS-AS-AP UCMS 203.0.113.0/24 AS14744 INTERNAP-BLOCK-4 - Internap Network Services Corporation 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.202.0/24 AS8513 SKYVISION SkyVision Global Networks Ltd 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Aug 3 17:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Aug 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201208032200.q73M01bn042709@wattle.apnic.net> BGP Update Report Interval: 26-Jul-12 -to- 02-Aug-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS5800 54239 3.2% 205.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 2 - AS8402 45483 2.7% 47.2 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 33335 1.9% 40.9 -- BSNL-NIB National Internet Backbone 4 - AS24560 30641 1.8% 48.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - AS17813 24694 1.4% 239.7 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 6 - AS7552 23873 1.4% 21.4 -- VIETEL-AS-AP Vietel Corporation 7 - AS13118 19067 1.1% 1121.6 -- ASN-YARTELECOM OJSC Rostelecom 8 - AS1637 18305 1.1% 254.2 -- DNIC-AS-01637 - Headquarters, USAISC 9 - AS27065 18027 1.1% 130.6 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 10 - AS27738 17548 1.0% 31.2 -- Ecuadortelecom S.A. 11 - AS174 14961 0.9% 7.1 -- COGENT Cogent/PSI 12 - AS17974 14924 0.9% 8.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS7029 12849 0.8% 6.5 -- WINDSTREAM - Windstream Communications Inc 14 - AS28573 11418 0.7% 8.5 -- NET Servicos de Comunicao S.A. 15 - AS13979 10622 0.6% 3.4 -- ATT-IPFR - AT&T Services, Inc. 16 - AS21599 10553 0.6% 3517.7 -- NETDIRECT S.A. 17 - AS45609 10305 0.6% 73.1 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service 18 - AS1502 10103 0.6% 140.3 -- DNIC-ASBLK-01500-01502 - Headquarters, USAISC 19 - AS1562 9890 0.6% 341.0 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 20 - AS11492 9827 0.6% 42.9 -- CABLEONE - CABLE ONE, INC. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16535 7104 0.4% 7104.0 -- ECHOS-3 - Echostar Holding Purchasing Corporation 2 - AS19406 4284 0.2% 4284.0 -- TWRS-MA - Towerstream I, Inc. 3 - AS21599 10553 0.6% 3517.7 -- NETDIRECT S.A. 4 - AS55534 2715 0.2% 2715.0 -- PPL-PK 4th Floor, PIDC House 5 - AS6197 2565 0.1% 2565.0 -- BATI-ATL - BellSouth Network Solutions, Inc 6 - AS36329 2276 0.1% 2276.0 -- INTRADO - Intrado, Inc. 7 - AS37343 9651 0.6% 1930.2 -- AirtelSeychelles 8 - AS44410 4601 0.3% 1533.7 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP 9 - AS13118 19067 1.1% 1121.6 -- ASN-YARTELECOM OJSC Rostelecom 10 - AS36938 995 0.1% 995.0 -- NIRA 11 - AS1273 5448 0.3% 908.0 -- CW Cable and Wireless Worldwide plc 12 - AS38857 1580 0.1% 790.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 13 - AS39214 1194 0.1% 597.0 -- COMINTECH Institute of Comunication and Information Technology 14 - AS6410 593 0.0% 593.0 -- ASICOM - ASI COMMUNICATIONS 15 - AS8382 1156 0.1% 578.0 -- IRTEL-AS Irkutsk Central Telegraph autonomous system 16 - AS49072 547 0.0% 547.0 -- APSUARA-AS TCA Apsuara Ltd. 17 - AS22767 1087 0.1% 543.5 -- NASA-ESDIS-NET - National Aeronautics and Space Administration 18 - AS55665 1019 0.1% 509.5 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 19 - AS29398 484 0.0% 484.0 -- PETROBALTIC "Petrobaltic" S.A. 20 - AS48068 476 0.0% 476.0 -- VISONIC Visonic Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 18909 1.0% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 122.161.0.0/16 11193 0.6% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 3 - 182.64.0.0/16 10861 0.6% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - 200.46.0.0/19 10547 0.6% AS21599 -- NETDIRECT S.A. 5 - 41.79.63.0/24 9620 0.5% AS37343 -- AirtelSeychelles AS45609 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service 6 - 41.79.62.0/24 9619 0.5% AS37343 -- AirtelSeychelles AS45609 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service 7 - 67.47.194.0/23 7104 0.4% AS16535 -- ECHOS-3 - Echostar Holding Purchasing Corporation 8 - 59.177.48.0/20 6538 0.4% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 9 - 202.56.215.0/24 6207 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 10 - 123.252.208.0/24 5753 0.3% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 11 - 139.139.19.0/24 5752 0.3% AS1562 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 12 - 194.63.9.0/24 5430 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 69.38.178.0/24 4284 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 14 - 59.177.64.0/18 3323 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 15 - 59.177.144.0/20 2954 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 16 - 78.111.6.0/23 2738 0.1% AS44410 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP 17 - 202.52.32.0/24 2715 0.1% AS55534 -- PPL-PK 4th Floor, PIDC House 18 - 65.82.30.0/24 2565 0.1% AS6197 -- BATI-ATL - BellSouth Network Solutions, Inc 19 - 115.170.128.0/17 2499 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 20 - 64.58.53.0/24 2276 0.1% AS36329 -- INTRADO - Intrado, Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jcurran at arin.net Fri Aug 3 17:03:24 2012 From: jcurran at arin.net (John Curran) Date: Fri, 3 Aug 2012 22:03:24 +0000 Subject: US House to ITU: Hands off the Internet In-Reply-To: <4873D44B-A5C3-4C28-B00A-7E02C4AB4E23@burkov.aha.ru> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> <4873D44B-A5C3-4C28-B00A-7E02C4AB4E23@burkov.aha.ru> Message-ID: <66F0321E-C029-4D63-9616-1BADF43129DF@arin.net> On Aug 3, 2012, at 5:57 PM, Dmitry Burkov wrote: > My opinion that the real problem laid in financial issues with developing countires Dmitry - There is a very real financial issue that developing countries face with affording the infrastructure that their citizens want to use (and often used to access to VoIP and streaming media services) I do think that there needs to be ample discussion of these concerns, but do not assume that a regulatory regime is the only available solution the issues raised. FYI, /John John Curran President and CEO ARIN From owen at delong.com Fri Aug 3 17:05:59 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Aug 2012 15:05:59 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> Message-ID: On Aug 3, 2012, at 14:17 , William Herrin wrote: > On Fri, Aug 3, 2012 at 10:01 AM, Owen DeLong wrote: >> On Aug 3, 2012, at 12:31 , William Herrin wrote: >>> Could be worse. I could have Pepco instead of Dominion. But it could >>> be better. And 20 years ago the reliability was. >> >> 20 years ago you didn't have a megabit to your home let alone many >> megabits. 20 years ago, POTS was much simpler than the converged >> networks we have today. There is something to be said for the simplicity >> of POTS. >> >> If you're that concerned about calling 911 for a heat stroke, why don't >> you maintain a POTS line? > > When Verizon installed FIOS in the neighborhood they removed the > copper lines to each house. It was understood and accepted that if the > household fiber adapters did not receive power the battery would fail > in a few hours. That the upstream would fail, even for folks who took > measures to continue to power the fiber adapter, was unexpected and > very unfortunate. If they can run a copper pair back to a powerable > location then it escapes me why they can't do the same with a single > strand of fiber. > Sounds like your beef should be with your local regulators that allowed them to remove the copper plant without providing adequate assurance of comparable service from the replacement. Owen > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From cb.list6 at gmail.com Fri Aug 3 17:12:42 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 3 Aug 2012 15:12:42 -0700 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: On Fri, Aug 3, 2012 at 12:22 PM, Otis L. Surratt, Jr. wrote: > Anyone charging end users for IPv6 space yet? :p > > Just wondering, with so many IPv6 resources in a single allocation it > would seem difficult to charge anything at all. > > 1. How are you making up loss of revenue on IPv4 assignments? > 2. Are you charging anything? > 3. Is the cost built into the service? > 4. Do you assign IPv6 space to end user and charge admin fee? > > Take care, > > Otis > IPv6 users cost me less money (CGN resources), i wish i had a business method for giving them discounts and meaningful incentives for using IPv6. Today, my retail mobile phones users can have 1 NAT'd IPv4 address or 2^64 public IPv6 addresses + NAT64 to reach IPv4 destinations. Most don't use the IPv6 address option yet :( But the number of folks electing to use IPv6 is increasing with more phones available (4 Androids now support HSPA+ IPv6) and more IPv6 awareness CB From derek at derekivey.com Fri Aug 3 17:37:06 2012 From: derek at derekivey.com (Derek Ivey) Date: Fri, 03 Aug 2012 18:37:06 -0400 Subject: IPv6 End User Fee In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: <501C5292.2030208@derekivey.com> If my ISP charged me fees for IPv6 space, I'd ditch them. They already make enough money as is from modem/cable box rentals. Derek On 8/3/2012 6:12 PM, Cameron Byrne wrote: > On Fri, Aug 3, 2012 at 12:22 PM, Otis L. Surratt, Jr. wrote: >> Anyone charging end users for IPv6 space yet? :p >> >> Just wondering, with so many IPv6 resources in a single allocation it >> would seem difficult to charge anything at all. >> >> 1. How are you making up loss of revenue on IPv4 assignments? >> 2. Are you charging anything? >> 3. Is the cost built into the service? >> 4. Do you assign IPv6 space to end user and charge admin fee? >> >> Take care, >> >> Otis >> > IPv6 users cost me less money (CGN resources), i wish i had a business > method for giving them discounts and meaningful incentives for using > IPv6. > > Today, my retail mobile phones users can have 1 NAT'd IPv4 address or > 2^64 public IPv6 addresses + NAT64 to reach IPv4 destinations. Most > don't use the IPv6 address option yet :( > > But the number of folks electing to use IPv6 is increasing with more > phones available (4 Androids now support HSPA+ IPv6) and more IPv6 > awareness > > CB > From nenolod at systeminplace.net Fri Aug 3 17:42:27 2012 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 3 Aug 2012 17:42:27 -0500 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: <23A5C997-B61E-41C0-9D7B-F2A48FD45682@systeminplace.net> Hi, On Aug 3, 2012, at 2:22 PM, "Otis L. Surratt, Jr." wrote: > Anyone charging end users for IPv6 space yet? :p > > Just wondering, with so many IPv6 resources in a single allocation it > would seem difficult to charge anything at all. > > 1. How are you making up loss of revenue on IPv4 assignments? If revenue from IPv4 assignments is an issue, then the solution is to adjust your business model to not depend on that revenue. As an ISP, the business is to ship bits around. > 2. Are you charging anything? Haven't ever charged for IPv6 allocations... > 3. Is the cost built into the service? The cost of IPv6 is so negligible (well unless you need advanced software licenses -- hi brocade), that I don't see any point in even accounting the cost of providing IPv6 into a service fee. > 4. Do you assign IPv6 space to end user and charge admin fee? By assign, do you mean SWIP? Some places charge an admin fee to do a SWIP, but for setting up an allocation, I have never heard of an admin fee. William From george.herbert at gmail.com Fri Aug 3 17:43:47 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 3 Aug 2012 15:43:47 -0700 Subject: IPv6 End User Fee In-Reply-To: <501C5292.2030208@derekivey.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <501C5292.2030208@derekivey.com> Message-ID: If anyone's ISPs are overcharging them, I will be able to provide service for no more than 1 cent per available routable IPv6 address in any netblock from /64 on up. We have a reasonable startup rate of a /56 for the price of a /64 for the remainder of 2012, even! -george On Fri, Aug 3, 2012 at 3:37 PM, Derek Ivey wrote: > If my ISP charged me fees for IPv6 space, I'd ditch them. They already make > enough money as is from modem/cable box rentals. > > Derek > > > On 8/3/2012 6:12 PM, Cameron Byrne wrote: >> >> On Fri, Aug 3, 2012 at 12:22 PM, Otis L. Surratt, Jr. >> wrote: >>> >>> Anyone charging end users for IPv6 space yet? :p >>> >>> Just wondering, with so many IPv6 resources in a single allocation it >>> would seem difficult to charge anything at all. >>> >>> 1. How are you making up loss of revenue on IPv4 assignments? >>> 2. Are you charging anything? >>> 3. Is the cost built into the service? >>> 4. Do you assign IPv6 space to end user and charge admin fee? >>> >>> Take care, >>> >>> Otis >>> >> IPv6 users cost me less money (CGN resources), i wish i had a business >> method for giving them discounts and meaningful incentives for using >> IPv6. >> >> Today, my retail mobile phones users can have 1 NAT'd IPv4 address or >> 2^64 public IPv6 addresses + NAT64 to reach IPv4 destinations. Most >> don't use the IPv6 address option yet :( >> >> But the number of folks electing to use IPv6 is increasing with more >> phones available (4 Androids now support HSPA+ IPv6) and more IPv6 >> awareness >> >> CB >> > > -- -george william herbert george.herbert at gmail.com From dburk at burkov.aha.ru Fri Aug 3 17:44:25 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sat, 4 Aug 2012 02:44:25 +0400 Subject: US House to ITU: Hands off the Internet In-Reply-To: <66F0321E-C029-4D63-9616-1BADF43129DF@arin.net> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> <4873D44B-A5C3-4C28-B00A-7E02C4AB4E23@burkov.aha.ru> <66F0321E-C029-4D63-9616-1BADF43129DF@arin.net> Message-ID: <745D190E-6616-41EA-B3EA-0D327E138032@burkov.aha.ru> The real issue is not laid in their economics - but in ours - our legacy players(mobile are the same) We simply try to hide our own problems behind their issues and use them again to protect our market interests - no more. On Aug 4, 2012, at 2:03 AM, John Curran wrote: > On Aug 3, 2012, at 5:57 PM, Dmitry Burkov > wrote: > >> My opinion that the real problem laid in financial issues with developing countires > > Dmitry - > > There is a very real financial issue that developing countries face > with affording the infrastructure that their citizens want to use > (and often used to access to VoIP and streaming media services) > > I do think that there needs to be ample discussion of these concerns, > but do not assume that a regulatory regime is the only available > solution the issues raised. > > FYI, > /John > > John Curran > President and CEO > ARIN > > > > From sethm at rollernet.us Fri Aug 3 17:44:38 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 03 Aug 2012 15:44:38 -0700 Subject: IPv6 End User Fee In-Reply-To: <23A5C997-B61E-41C0-9D7B-F2A48FD45682@systeminplace.net> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <23A5C997-B61E-41C0-9D7B-F2A48FD45682@systeminplace.net> Message-ID: <501C5456.8020207@rollernet.us> On 8/3/12 3:42 PM, William Pitcock wrote: > Hi, > > On Aug 3, 2012, at 2:22 PM, "Otis L. Surratt, Jr." wrote: > >> Anyone charging end users for IPv6 space yet? :p >> >> Just wondering, with so many IPv6 resources in a single allocation it >> would seem difficult to charge anything at all. >> >> 1. How are you making up loss of revenue on IPv4 assignments? > > If revenue from IPv4 assignments is an issue, then the solution is to adjust your business model to not depend on that revenue. As an ISP, the business is to ship bits around. > To that end I've never charged for IPv4, either. ~Seth From jcurran at arin.net Fri Aug 3 18:08:50 2012 From: jcurran at arin.net (John Curran) Date: Fri, 3 Aug 2012 23:08:50 +0000 Subject: US House to ITU: Hands off the Internet In-Reply-To: <745D190E-6616-41EA-B3EA-0D327E138032@burkov.aha.ru> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> <4873D44B-A5C3-4C28-B00A-7E02C4AB4E23@burkov.aha.ru> <66F0321E-C029-4D63-9616-1BADF43129DF@arin.net> <745D190E-6616-41EA-B3EA-0D327E138032@burkov.aha.ru> Message-ID: <5CD4478F-E893-4717-80F6-5C71295AF223@corp.arin.net> On Aug 3, 2012, at 6:44 PM, Dmitry Burkov wrote: > The real issue is not laid in their economics - but in ours - our legacy players(mobile are the same) > We simply try to hide our own problems behind their issues and use them again to protect our market interests > - no more. Dmitry - We're quickly leaving the realm of network operations, but it might be helpful if you could further explain what you mean by the above (as it's not particularly clear what you mean by "our own problems") /John John Curran President and CEO ARIN From dburk at burkov.aha.ru Fri Aug 3 18:13:53 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sat, 4 Aug 2012 03:13:53 +0400 Subject: US House to ITU: Hands off the Internet In-Reply-To: <745D190E-6616-41EA-B3EA-0D327E138032@burkov.aha.ru> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> <4873D44B-A5C3-4C28-B00A-7E02C4AB4E23@burkov.aha.ru> <66F0321E-C029-4D63-9616-1BADF43129DF@arin.net> <745D190E-6616-41EA-B3EA-0D327E138032@burkov.aha.ru> Message-ID: <5A299726-1547-437A-88DB-A0F1CC1FC042@burkov.aha.ru> in my stupid opinion it is the problem of a new global still developing global market - key dominated players are from our countries - which see on them as on strategical national strategic assets. Should I explain more? Or it is already clear? I classified censorship and IPR protection in the same manner or I mistaken? On Aug 4, 2012, at 2:44 AM, Dmitry Burkov wrote: > The real issue is not laid in their economics - but in ours - our legacy players(mobile are the same) > We simply try to hide our own problems behind their issues and use them again to protect our market interests > - no more. > > > On Aug 4, 2012, at 2:03 AM, John Curran wrote: > >> On Aug 3, 2012, at 5:57 PM, Dmitry Burkov >> wrote: >> >>> My opinion that the real problem laid in financial issues with developing countires >> >> Dmitry - >> >> There is a very real financial issue that developing countries face >> with affording the infrastructure that their citizens want to use >> (and often used to access to VoIP and streaming media services) >> >> I do think that there needs to be ample discussion of these concerns, >> but do not assume that a regulatory regime is the only available >> solution the issues raised. >> >> FYI, >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> > > From otis at ocosa.com Fri Aug 3 18:32:55 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Fri, 3 Aug 2012 18:32:55 -0500 Subject: IPv6 End User Fee References: Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8BCCD5@ocsbs.ocosa.com> By end user I mean hosting clients (cloud, collocation, shared, dedicated, VPS, etc.) of any sort. For example you have clients that would need....say /24 for their dedicated server. If you charge a $1.00/IP which is typical then you would lose that revenue if they converted to IPv6. If you didn't charge for IPv4 then you have nothing to to lose. Otis ________________________________ From: Cutler James R [mailto:james.cutler at consultant.com] Sent: Fri 8/3/2012 3:48 PM To: Otis L. Surratt, Jr. Cc: NANOG list Subject: Re: IPv6 End User Fee On Aug 3, 2012, at 3:22 PM, "Otis L. Surratt, Jr." wrote: > Anyone charging end users for IPv6 space yet? :p > > > Otis > I can't imagine that this would be anything but counterproductive. End users are not interested in IPv6 - most would not recognize IPv6 if it fell out of their screen. End users want working connectivity, not jargon. James R. Cutler james.cutler at consultant.com From nanog-post at rsuc.gweep.net Fri Aug 3 18:56:39 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 3 Aug 2012 19:56:39 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> Message-ID: <20120803235638.GA40947@gweep.net> On Fri, Aug 03, 2012 at 01:01:35PM -0700, Owen DeLong wrote: [snip] > If you're that concerned about calling 911 for a heat stroke, why don't > you maintain a POTS line? Choices are great but carry responsibility and result in consequences. Some folks don't like to hear that, or just can't be bothered to read the "* not lifeline or E911 service" on a product description. Joe "had no problem keeping a POTS line when getting FiOS installed" Provo -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From mansaxel at besserwisser.org Fri Aug 3 19:02:23 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 4 Aug 2012 02:02:23 +0200 Subject: US House to ITU: Hands off the Internet In-Reply-To: <5A299726-1547-437A-88DB-A0F1CC1FC042@burkov.aha.ru> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <19E2449C-7352-4E19-AC2E-00836E379A41@arin.net> <4873D44B-A5C3-4C28-B00A-7E02C4AB4E23@burkov.aha.ru> <66F0321E-C029-4D63-9616-1BADF43129DF@arin.net> <745D190E-6616-41EA-B3EA-0D327E138032@burkov.aha.ru> <5A299726-1547-437A-88DB-A0F1CC1FC042@burkov.aha.ru> Message-ID: <20120804000223.GK5716@besserwisser.org> Subject: Re: US House to ITU: Hands off the Internet Date: Sat, Aug 04, 2012 at 03:13:53AM +0400 Quoting Dmitry Burkov (dburk at burkov.aha.ru): > in my stupid opinion it is the problem of a new global still developing global market - key dominated players are from our countries - which see on them as on strategical national strategic assets. Should I explain more? > Or it is already clear? > > I classified censorship and IPR protection in the same manner or I mistaken? The problem with the ITU idea (apart from being to a certain extent a me-too scheme) is that it is playing in the hands of nation-states that wish to regulate flows of revenue and information in a manner that is detrimental to operational practices for running networks efficiently (on-topic) and business models for operators (somewhat on-topic) -- and then we haven't even gotten started on the phenomenal possibilities of instigating government-run monopolies and information chokepoints by implementing network infrastructure and adressing plans as if IP was E.164 and there only was one ISP per country. (slightly off-topic) Support for these ideas can -- IMNSHO -- only come from those who have something to lose when there is free flow of information and free establisment of business relations. Far from wanting to taint the entire ITU by universal attribution I'd suspect that this is the brain-child of a number of distinct nation-states who have identified themselves as possibly in need of thwarted cashflow (from gov't-supported monopolies with fantasy pricing schemes) or feel that they need to alter the information picture for their subjects. Either that or the entire ITU-T still believes that SS7 scales better than BGP. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 SANTA CLAUS comes down a FIRE ESCAPE wearing bright blue LEG WARMERS ... He scrubs the POPE with a mild soap or detergent for 15 minutes, starring JANE FONDA!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nenolod at systeminplace.net Fri Aug 3 20:00:52 2012 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 3 Aug 2012 20:00:52 -0500 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8BCCD5@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8BCCD5@ocsbs.ocosa.com> Message-ID: <1C919FDE-D6B6-4167-BBE7-9FE3222F3ECF@systeminplace.net> Hi! On Aug 3, 2012, at 6:32 PM, "Otis L. Surratt, Jr." wrote: > By end user I mean hosting clients (cloud, collocation, shared, dedicated, VPS, etc.) of any sort. For example you have clients that would need....say /24 for their dedicated server. If you charge a $1.00/IP which is typical then you would lose that revenue if they converted to IPv6. If you didn't charge for IPv4 then you have nothing to to lose. > A possible revenue-recovery model would be to charge say $2 per IP for services below a certain resource threshold, for example 1gb vps or larger get free IPs and dedicated servers get free IPs. This helps to increase margin as some people will upgrade to more expensive plans to get the free IPv4s. In hosting you can just issue /128s on ipv6 and require upgrades to get larger allocations. William > Otis > > ________________________________ > > From: Cutler James R [mailto:james.cutler at consultant.com] > Sent: Fri 8/3/2012 3:48 PM > To: Otis L. Surratt, Jr. > Cc: NANOG list > Subject: Re: IPv6 End User Fee > > > > On Aug 3, 2012, at 3:22 PM, "Otis L. Surratt, Jr." wrote: >> Anyone charging end users for IPv6 space yet? :p >> >> >> Otis >> > > I can't imagine that this would be anything but counterproductive. End users are not interested in IPv6 - most would not recognize IPv6 if it fell out of their screen. End users want working connectivity, not jargon. > > James R. Cutler > james.cutler at consultant.com > > > Sent from my Sprint iPhone From mysidia at gmail.com Fri Aug 3 21:08:17 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 3 Aug 2012 21:08:17 -0500 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: On 8/3/12, Otis L. Surratt, Jr. wrote: > Anyone charging end users for IPv6 space yet? :p > ISPs already charge for bandwidth link capacity. Why charge a fee to discourage subscribers from adopting a protocol that will let the ISP sell larger capacity links? IPv6 packet headers are 40 bytes length, Versus IPv4 headers which were ~20 bytes. -- -JH From jordi.palet at consulintel.es Fri Aug 3 21:49:34 2012 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 03 Aug 2012 19:49:34 -0700 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: Add value. You must not charge for the addresses at all, they are not yours, you can't sell them. In every "smart" business, the future is not anymore selling "goods" but added value. If you have a quasi-unlimited number of addresses in every customer, you can star building up new value added services and applications, either in-house or with the cooperation of third-party developers, such as in the case of the app-store and likes. You will ger a small revenue for every new service or app, but times many customers/month, and this will increase the demand of bw, so you will be able to sell bigger pipes. Regards, Jordi -----Mensaje original----- De: "Otis L. Surratt, Jr." Responder a: Fecha: viernes 3 de agosto de 2012 12:22 Para: Asunto: IPv6 End User Fee >Anyone charging end users for IPv6 space yet? :p > >Just wondering, with so many IPv6 resources in a single allocation it >would seem difficult to charge anything at all. > >1. How are you making up loss of revenue on IPv4 assignments? >2. Are you charging anything? >3. Is the cost built into the service? >4. Do you assign IPv6 space to end user and charge admin fee? > >Take care, > >Otis > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From james.cutler at consultant.com Fri Aug 3 22:04:51 2012 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 3 Aug 2012 23:04:51 -0400 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8BCCD5@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8BCCD5@ocsbs.ocosa.com> Message-ID: <3CD3BC75-D8AF-457E-9D90-02F4EA5B6D32@consultant.com> I would say that the typical usage, at least here in the US, is that an End User is the one holding an iPhone or sitting at a computer watching the Olympics, and, ultimately, paying that last mile fee. Even using your definition, the costs of connectivity (routers, wires, management) far exceeds the cost of addressing. Given the quantity of numbers available for IP addressing, it is does not make economic sense to even construct a billing mechanism for IPv6 addressing beyond those of the LIRs, RIRs, etc. Purchase IPv6 connectivity includes the assumption of IPv6 addressing included. On Aug 3, 2012, at 7:32 PM, "Otis L. Surratt, Jr." wrote: > By end user I mean hosting clients (cloud, collocation, shared, dedicated, VPS, etc.) of any sort. For example you have clients that would need....say /24 for their dedicated server. If you charge a $1.00/IP which is typical then you would lose that revenue if they converted to IPv6. If you didn't charge for IPv4 then you have nothing to to lose. > > Otis > > From: Cutler James R [mailto:james.cutler at consultant.com] > Sent: Fri 8/3/2012 3:48 PM > To: Otis L. Surratt, Jr. > Cc: NANOG list > Subject: Re: IPv6 End User Fee > > On Aug 3, 2012, at 3:22 PM, "Otis L. Surratt, Jr." wrote: > > Anyone charging end users for IPv6 space yet? :p > > > > > > Otis > > > > I can't imagine that this would be anything but counterproductive. End users are not interested in IPv6 - most would not recognize IPv6 if it fell out of their screen. End users want working connectivity, not jargon. > > James R. Cutler > james.cutler at consultant.com > > From frnkblk at iname.com Fri Aug 3 22:07:37 2012 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 3 Aug 2012 22:07:37 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> Message-ID: <007301cd71ee$4d4b2d60$e7e18820$@iname.com> As someone else posted, many FTTH installations are centralized as much as possible to avoid having non-passive equipment in the plant, allowing for the practicality of onsite generators. That's what we do. But for those who have powered nodes in the field (distributed/tiered BPON or GPON configurations and cable plants), it's not realistic to keep them all powered. Despite what the DOT may be able to do. Frank -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Friday, August 03, 2012 4:53 PM To: frnkblk at iname.com Cc: nanog at nanog.org; Seth Mattinen Subject: Re: Verizon FiOS - is BGP an option? On Fri, Aug 3, 2012 at 11:26 AM, Frank Bulk wrote: > A good portable generator is more than $500, and if it's a wide-spread > outage there's not enough portable generators to go around, and if there > were, not enough people to set them and give them their fluids. Doesn't take a "good" generator to maintain a -48V battery string. Drop it off. Plug it in. Start it up. Task some folks on an 8 hour loop to keep the tanks topped off. If the DOT, not noted for its efficiency, can get the major traffic lights up and running on generators the next day, why can't Sprint, Cox and Verizon get their towers and fiber concentrators powered up? That's a condemnation worthy of the word: that your company performed worse in the storm recovery than the local department of transportation. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Fri Aug 3 22:22:44 2012 From: randy at psg.com (Randy Bush) Date: Fri, 03 Aug 2012 20:22:44 -0700 Subject: IPv6 End User Fee In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: > You must not charge for the addresses at all, they are not > yours, you can't sell them. do i pay for them? From owen at delong.com Fri Aug 3 22:31:06 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Aug 2012 20:31:06 -0700 Subject: IPv6 End User Fee In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: <15599C39-A2F0-41ED-9148-DFE42A971764@delong.com> On Aug 3, 2012, at 20:22 , Randy Bush wrote: >> You must not charge for the addresses at all, they are not >> yours, you can't sell them. > > do i pay for them? NO, you don't. You _MIGHT_ pay for registration services where you are paying for the service of having them uniquely registered in the RIR system. You MIGHT have paid some other organization for the privilege of transferring part or all of their registration rights to you. But in no case did you pay for the addresses themselves unless you are silly enough to think that a person can own an integer. Owen From otis at ocosa.com Fri Aug 3 23:05:39 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Fri, 3 Aug 2012 23:05:39 -0500 Subject: IPv6 End User Fee References: <5FE1FB6D43B8A647BBC821840C1AEA8BCCD5@ocsbs.ocosa.com> <3CD3BC75-D8AF-457E-9D90-02F4EA5B6D32@consultant.com> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8BCCDC@ocsbs.ocosa.com> I was thinking about End User in a sense of one to simply consume a product or a service offered by a service provider. However, I should have left room for those that are assigned GUA space by a service provider and reassign space to their end users. (i.e. Allocated /48 and reassign /64 or /56) I do agree that the infrastructure and management costs out way the costs of provider independent space. I agree it would be extremely difficult to setup some sort of fee for any prefix size in IPv6. Then it's fair to say the approach should be simply to chalk the lose in IPv4 revenue and move on. It's not a big concern for us. I was just curious as to the large providers that make extra money off those wanting more IPv4 addresses. -----Original Message----- From: Cutler James R [mailto:james.cutler at consultant.com] Sent: Fri 8/3/2012 10:04 PM To: Otis L. Surratt, Jr. Cc: NANOG list Subject: Re: IPv6 End User Fee I would say that the typical usage, at least here in the US, is that an End User is the one holding an iPhone or sitting at a computer watching the Olympics, and, ultimately, paying that last mile fee. Even using your definition, the costs of connectivity (routers, wires, management) far exceeds the cost of addressing. Given the quantity of numbers available for IP addressing, it is does not make economic sense to even construct a billing mechanism for IPv6 addressing beyond those of the LIRs, RIRs, etc. Purchase IPv6 connectivity includes the assumption of IPv6 addressing included. On Aug 3, 2012, at 7:32 PM, "Otis L. Surratt, Jr." wrote: > By end user I mean hosting clients (cloud, collocation, shared, dedicated, VPS, etc.) of any sort. For example you have clients that would need....say /24 for their dedicated server. If you charge a $1.00/IP which is typical then you would lose that revenue if they converted to IPv6. If you didn't charge for IPv4 then you have nothing to to lose. > > Otis > > From: Cutler James R [mailto:james.cutler at consultant.com] > Sent: Fri 8/3/2012 3:48 PM > To: Otis L. Surratt, Jr. > Cc: NANOG list > Subject: Re: IPv6 End User Fee > > On Aug 3, 2012, at 3:22 PM, "Otis L. Surratt, Jr." wrote: > > Anyone charging end users for IPv6 space yet? :p > > > > > > Otis > > > > I can't imagine that this would be anything but counterproductive. End users are not interested in IPv6 - most would not recognize IPv6 if it fell out of their screen. End users want working connectivity, not jargon. > > James R. Cutler > james.cutler at consultant.com > > From valdis.kletnieks at vt.edu Fri Aug 3 23:26:53 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 04 Aug 2012 00:26:53 -0400 Subject: US House to ITU: Hands off the Internet In-Reply-To: Your message of "Fri, 03 Aug 2012 14:06:19 -0400." <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> Message-ID: <169584.1344054413@turing-police.cc.vt.edu> On Fri, 03 Aug 2012 14:06:19 -0400, "Patrick W. Gilmore" said: > The vote was unanimous: 414-0 > > Unanimous? I didn't think this congress could agree the earth is round unanimously. And in fact, they didn't - there's 435 Representatives. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From r.engehausen at gmail.com Sat Aug 4 00:08:44 2012 From: r.engehausen at gmail.com (Roy) Date: Fri, 03 Aug 2012 22:08:44 -0700 Subject: US House to ITU: Hands off the Internet In-Reply-To: <169584.1344054413@turing-police.cc.vt.edu> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <169584.1344054413@turing-police.cc.vt.edu> Message-ID: <501CAE5C.5030206@gmail.com> On 8/3/2012 9:26 PM, valdis.kletnieks at vt.edu wrote: > On Fri, 03 Aug 2012 14:06:19 -0400, "Patrick W. Gilmore" said: >> The vote was unanimous: 414-0 >> >> Unanimous? I didn't think this congress could agree the earth is round unanimously. > And in fact, they didn't - there's 435 Representatives. Actually 430. There were 16 "Not Voting". Five seats must be empty. Republican 229 10 Democratic 185 6 TOTALS 414 16 From owen at delong.com Sat Aug 4 01:17:43 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Aug 2012 23:17:43 -0700 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8BCCDC@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8BCCD5@ocsbs.ocosa.com> <3CD3BC75-D8AF-457E-9D90-02F4EA5B6D32@consultant.com> <5FE1FB6D43B8A647BBC821840C1AEA8BCCDC@ocsbs.ocosa.com> Message-ID: <75DC923B-E197-41FF-999C-A20BA0179842@delong.com> On Aug 3, 2012, at 21:05 , "Otis L. Surratt, Jr." wrote: > I was thinking about End User in a sense of one to simply consume a product or a service offered by a service provider. However, I should have left room for those that are assigned GUA space by a service provider and reassign space to their end users. (i.e. Allocated /48 and reassign /64 or /56) That shouldn't happen... If you are acting as an LIR, you should be getting at least a /32 and you should be assigning at least a /48 to your end users. > I do agree that the infrastructure and management costs out way the costs of provider independent space. I agree it would be extremely difficult to setup some sort of fee for any prefix size in IPv6. > > Then it's fair to say the approach should be simply to chalk the lose in IPv4 revenue and move on. It's not a big concern for us. I was just curious as to the large providers that make extra money off those wanting more IPv4 addresses. Is it really a loss? If you're doing things right, IPv4 is costing you more and more and more money every year. When your IPv4 revenue goes away, so should your IPv4 costs. Owen > > > > -----Original Message----- > From: Cutler James R [mailto:james.cutler at consultant.com] > Sent: Fri 8/3/2012 10:04 PM > To: Otis L. Surratt, Jr. > Cc: NANOG list > Subject: Re: IPv6 End User Fee > > I would say that the typical usage, at least here in the US, is that an End User is the one holding an iPhone or sitting at a computer watching the Olympics, and, ultimately, paying that last mile fee. > > Even using your definition, the costs of connectivity (routers, wires, management) far exceeds the cost of addressing. Given the quantity of numbers available for IP addressing, it is does not make economic sense to even construct a billing mechanism for IPv6 addressing beyond those of the LIRs, RIRs, etc. Purchase IPv6 connectivity includes the assumption of IPv6 addressing included. > > On Aug 3, 2012, at 7:32 PM, "Otis L. Surratt, Jr." wrote: >> By end user I mean hosting clients (cloud, collocation, shared, dedicated, VPS, etc.) of any sort. For example you have clients that would need....say /24 for their dedicated server. If you charge a $1.00/IP which is typical then you would lose that revenue if they converted to IPv6. If you didn't charge for IPv4 then you have nothing to to lose. >> >> Otis >> >> From: Cutler James R [mailto:james.cutler at consultant.com] >> Sent: Fri 8/3/2012 3:48 PM >> To: Otis L. Surratt, Jr. >> Cc: NANOG list >> Subject: Re: IPv6 End User Fee >> >> On Aug 3, 2012, at 3:22 PM, "Otis L. Surratt, Jr." wrote: >>> Anyone charging end users for IPv6 space yet? :p >>> >>> >>> Otis >>> >> >> I can't imagine that this would be anything but counterproductive. End users are not interested in IPv6 - most would not recognize IPv6 if it fell out of their screen. End users want working connectivity, not jargon. >> >> James R. Cutler >> james.cutler at consultant.com >> >> > > From eugen at leitl.org Sat Aug 4 03:41:04 2012 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 4 Aug 2012 10:41:04 +0200 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> Message-ID: <20120804084104.GE12615@leitl.org> On Fri, Aug 03, 2012 at 11:52:53AM -1000, William Herrin wrote: > On Fri, Aug 3, 2012 at 11:26 AM, Frank Bulk wrote: > > A good portable generator is more than $500, and if it's a wide-spread > > outage there's not enough portable generators to go around, and if there > > were, not enough people to set them and give them their fluids. > > Doesn't take a "good" generator to maintain a -48V battery string. > Drop it off. Plug it in. Start it up. Task some folks on an 8 hour > loop to keep the tanks topped off. Even battery-buffered overnight, solar PV works great if grid is down or even completely absent. > If the DOT, not noted for its efficiency, can get the major traffic > lights up and running on generators the next day, why can't Sprint, > Cox and Verizon get their towers and fiber concentrators powered up? > That's a condemnation worthy of the word: that your company performed > worse in the storm recovery than the local department of > transportation. From eugen at leitl.org Sat Aug 4 05:01:11 2012 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 4 Aug 2012 12:01:11 +0200 Subject: IPv6 End User Fee In-Reply-To: <15599C39-A2F0-41ED-9148-DFE42A971764@delong.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <15599C39-A2F0-41ED-9148-DFE42A971764@delong.com> Message-ID: <20120804100111.GS12615@leitl.org> On Fri, Aug 03, 2012 at 08:31:06PM -0700, Owen DeLong wrote: > You MIGHT have paid some other organization for the privilege of transferring part or all of their registration rights to you. > > But in no case did you pay for the addresses themselves unless you are silly enough to think that a person can own an integer. IPv6 missed a great chance of doing away with all the central waterfall trickle-down space distribution. Luckily, /64 looks like large enough to bypass that by offering address space sufficiently large while co-existable with legacy addressing and routing. I hope eventually somebody will start tinkering with mesh radios which also have GPS onboard (as most smartphones and tablets do). 24 + 24 + 16 bits are just enough to represent a decent-resolution WGS84 position fix. Plus, GPS gives you a pretty accurate clock. From cmadams at hiwaay.net Sat Aug 4 10:02:12 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 4 Aug 2012 10:02:12 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <00cd01cd71be$b56718d0$20354a70$@iname.com> References: <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> Message-ID: <20120804150212.GB22887@hiwaay.net> Once upon a time, Frank Bulk said: > A good portable generator is more than $500, and if it's a wide-spread > outage there's not enough portable generators to go around, and if there > were, not enough people to set them and give them their fluids. And it > doesn't pay to put a natural gas (or similar) generator at every node for > those rare instances where the battery does not suffice. That's what Bellsouth did here (haven't seen any new fiber huts in my area since AT&T took over to know if they're still doing it). Every fiber hut is on a larger concrete pad that has a second power hut with a natural gas line hooked up. Of course, last year when we had a week-long power outage due to tornados taking out over 200 high-voltage distribution towers, my DSL and phone went down after a while anyway, because mine runs to a fiber hut old enough to be an actual hut (looks like a little pump house) from before they set them up with the generators. I'm not sure how long it was up because _I_ didn't have a generator (and then I left town). As for portable generators: I'm in Huntsville, AL, which is not exactly a huge city, and I'm pretty sure there are well over a hundred fiber huts around here. Storing, maintaining, deploying, and supplying that many portable generators is not practical, especially when they'll be needed at a time when you probably need all hands in the field repairing the plant itself. Besides, where do you think you're going to get gasoline in a wide-spread extended power failure? Few gas stations have generators, and even if they do, they'll sell out of gas quickly. That distribution system also needs power. The diesel for our generator had to be trucked in from outside the affected area (Birmingham IIRC). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bill at herrin.us Sat Aug 4 10:02:33 2012 From: bill at herrin.us (William Herrin) Date: Sat, 4 Aug 2012 11:02:33 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <20120804084104.GE12615@leitl.org> References: <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804084104.GE12615@leitl.org> Message-ID: On Sat, Aug 4, 2012 at 4:41 AM, Eugen Leitl wrote: > On Fri, Aug 03, 2012 at 11:52:53AM -1000, William Herrin wrote: >> On Fri, Aug 3, 2012 at 11:26 AM, Frank Bulk wrote: >> > A good portable generator is more than $500, and if it's a wide-spread >> > outage there's not enough portable generators to go around, and if there >> > were, not enough people to set them and give them their fluids. >> >> Doesn't take a "good" generator to maintain a -48V battery string. >> Drop it off. Plug it in. Start it up. Task some folks on an 8 hour >> loop to keep the tanks topped off. > > Even battery-buffered overnight, solar PV works great if grid is > down or even completely absent. That's a clever idea but for the kind of equipment in question you'd need a dozen square yards of cells. That isn't available where most of these installations are. Though perhaps the utilities should have made an effort to site them where it could be. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Sat Aug 4 10:15:16 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 4 Aug 2012 10:15:16 -0500 Subject: US House to ITU: Hands off the Internet In-Reply-To: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> Message-ID: On 8/3/12, Patrick W. Gilmore wrote: "it is the "consistent and unequivocal policy of the United States to promote a global Internet free from government control." Now if they would only practice what they preach..... > [Feels operational to me.] > > -- -JH From bill at herrin.us Sat Aug 4 10:15:05 2012 From: bill at herrin.us (William Herrin) Date: Sat, 4 Aug 2012 11:15:05 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <20120804150212.GB22887@hiwaay.net> References: <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> Message-ID: On Sat, Aug 4, 2012 at 11:02 AM, Chris Adams wrote: > Besides, where do you think you're going to get gasoline in a > wide-spread extended power failure? Few gas stations have generators, > and even if they do, they'll sell out of gas quickly. That distribution > system also needs power. The diesel for our generator had to be trucked > in from outside the affected area (Birmingham IIRC). I managed to get gasoline for my generator. I had to drive upwards of 5 miles and pass as many as 7 closed stations to get it. But it was available and if I'd planned better with respect to containers to carry it in I'd have had zero difficulty. Some stations did have generators. And some were in locations that didn't lose power in the first place. The kind of event which ends access to fuel tends to destroy the communications infrastructure anyway so that loss of power is not the main barrier to operations. Extended loss of power is a regular, high-probability threat. I think it reasonable to expect the local communications companies to be ready for it and capable of keeping the key infrastructure online. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mikejones.in Sat Aug 4 10:44:11 2012 From: mike at mikejones.in (Mike Jones) Date: Sat, 4 Aug 2012 16:44:11 +0100 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <007301cd71ee$4d4b2d60$e7e18820$@iname.com> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <007301cd71ee$4d4b2d60$e7e18820$@iname.com> Message-ID: On 4 August 2012 04:07, Frank Bulk wrote: > As someone else posted, many FTTH installations are centralized as much as > possible to avoid having non-passive equipment in the plant, allowing for > the practicality of onsite generators. That's what we do. But for those > who have powered nodes in the field (distributed/tiered BPON or GPON > configurations and cable plants), it's not realistic to keep them all > powered. Despite what the DOT may be able to do. If only they had some kind of copper cabling running from some kind of central location (like perhaps the same place the fiber runs to, I imagine the same buildings that the old POTS lines ran to) that went all the way out to the huts full of powered equipment (that would likely be next to the old POTS junction boxes) that as a result of their new fiber installs would have a few pairs unused, then they could possibly have hooked those up as backup power when grid power becomes unavailable for a large area (poor power distribution efficiency would probably stop you wanting to power it that way all the time). It's a shame that there isn't any such copper infrastructure owned by those same companies already in place, but perhaps they could have thrown an extra copper cable in to the middle of that fiber bundle at the same time they were running it at negligible additional cost. - Mike From streiner at cluebyfour.org Sat Aug 4 10:55:25 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 4 Aug 2012 11:55:25 -0400 (EDT) Subject: US House to ITU: Hands off the Internet In-Reply-To: References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> Message-ID: On Sat, 4 Aug 2012, Jimmy Hess wrote: > On 8/3/12, Patrick W. Gilmore wrote: > "it is the "consistent and unequivocal policy of the United States to > promote a global Internet free from government control." > > Now if they would only practice what they preach..... It will be interesting to see how that statement gets (ab)used the next time net neutrality, or legislation like SOPA/PIPA becomes a hot topic. jms From mysidia at gmail.com Sat Aug 4 10:59:09 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 4 Aug 2012 10:59:09 -0500 Subject: IPv6 End User Fee In-Reply-To: <20120804100111.GS12615@leitl.org> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <15599C39-A2F0-41ED-9148-DFE42A971764@delong.com> <20120804100111.GS12615@leitl.org> Message-ID: On 8/4/12, Eugen Leitl wrote: > On Fri, Aug 03, 2012 at 08:31:06PM -0700, Owen DeLong wrote: > onboard (as most smartphones and tablets do). > 24 + 24 + 16 bits are just enough to represent > a decent-resolution WGS84 position fix. Plus, > GPS gives you a pretty accurate clock. Yes, very interesting. I wonder how do you achieve full scale software testing for a mesh networking platform efficiently? Do any of the virtual machine monitors Xen, KVM, etc support an emulated 802.11n/other radio device that allows you to configure "Emulated location and geography" for each virtual node, to test various protocols and implementations across p2p wireless meshes by simulating realistic connectivity performance? -- -JH From cmadams at hiwaay.net Sat Aug 4 11:09:04 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 4 Aug 2012 11:09:04 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> Message-ID: <20120804160904.GC22887@hiwaay.net> Once upon a time, William Herrin said: > I managed to get gasoline for my generator. I had to drive upwards of > 5 miles and pass as many as 7 closed stations to get it. But it was > available and if I'd planned better with respect to containers to > carry it in I'd have had zero difficulty. Some stations did have > generators. And some were in locations that didn't lose power in the > first place. Well, in North Alabama in April 2011, we had to drive a lot more than 5 miles (unless you left a 0 off the end). Across the Tennessee state line (a good bit north of it) they had power, but they quickly ran out of gas (and had a several hour wait in line to get what they had). I was headed to Atlanta, and in 100 miles I drove past just one open gas station (with very long lines) before I filled up in Georgia. This was an exceptional event; it was the first time ever Huntsville Utilities had lost all power. TVA shut down a large nuclear plant (Browns Ferry) not because of any problem at the plant (although they also lost off-site power because of a close tornado, which by regulation requires a shutdown) but because there was nowhere for the power to go. > The kind of event which ends access to fuel tends to destroy the > communications infrastructure anyway so that loss of power is not the > main barrier to operations. It depends. Our problems were from tornados, which tend to cause very localized damage in a relatively narrow path (it can be 50+ miles long but not usually more than a half-mile to a mile wide). Even a massive outbreak didn't cause any damage at all to 90%+ of the population. We lost power because the distribution system was severly hit, but the long-haul fiber all stayed up. Most of the other problems were because of the power failure (some local fiber rings dropped, especially one CLEC's that puts their nodes in customer premises and were broken by customers' power failures). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From eugen at leitl.org Sat Aug 4 11:35:44 2012 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 4 Aug 2012 18:35:44 +0200 Subject: IPv6 End User Fee In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <15599C39-A2F0-41ED-9148-DFE42A971764@delong.com> <20120804100111.GS12615@leitl.org> Message-ID: <20120804163544.GJ12615@leitl.org> On Sat, Aug 04, 2012 at 10:59:09AM -0500, Jimmy Hess wrote: > On 8/4/12, Eugen Leitl wrote: > > On Fri, Aug 03, 2012 at 08:31:06PM -0700, Owen DeLong wrote: > > onboard (as most smartphones and tablets do). > > 24 + 24 + 16 bits are just enough to represent > > a decent-resolution WGS84 position fix. Plus, > > GPS gives you a pretty accurate clock. > > Yes, very interesting. I wonder how do you achieve full scale > software testing for a mesh networking platform efficiently? The Serval people do physical testing in the lab and the field. Of course, their scale is very small. You'd want to push most traffic through regular IPv6 Internet and only everything else through the mesh which doesn't have direct line of sight or fiber connectivity. This can be impemented as an abstract layer presenting a unified view, which uses VPN tunnels (each router node would not need to maintain many, even modest connectivites would result in very few hops) over IPv6 Internet just as Tor or I2P do it today. The penalty would be not that bad, given that you're not doing any deliberate traffic remixing/onion routing. You can prototype something like that quite easily based on CyanogenMod with IPv6, OpenVPN or tinc, gpsd, Serval, (maybe cjdns https://raw.github.com/cjdelisle/cjdns/master/rfcs/Whitepaper.md as well?) and some glue to tie it all together. > Do any of the virtual machine monitors Xen, KVM, etc > support an emulated 802.11n/other radio device that allows you to > configure "Emulated location and geography" for each virtual node, > to test various protocols and implementations across p2p wireless > meshes by simulating realistic connectivity performance? Very good point. I'm not aware of simulators which can do that on a very large scale (millions, billions to trillions of nodes). From mysidia at gmail.com Sat Aug 4 11:41:13 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 4 Aug 2012 11:41:13 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <20120804160904.GC22887@hiwaay.net> References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <20120804160904.GC22887@hiwaay.net> Message-ID: On 8/4/12, Chris Adams wrote: > long-haul fiber all stayed up. Most of the other problems were because > of the power failure (some local fiber rings dropped, especially one > CLEC's that puts their nodes in customer premises and were broken by > customers' power failures). [snip] I would go as far as to say most electric utilities I know of specialize in safe efficient long-distance transmission for a mass consumption audience (massive number of users, very few users with specific high reliability requirements who can't accept a 5 day outage at least), and favor safety and efficiency over reliability, using many components that are not buried or heavily shielded, and are highly susceptible to weather events, trucks knocking poles over, lightning, tornados, solar flares, etc, and that their answer to outage prevention is to let it fail, or shut it down in case of damage, and then repair later. If a telco provider's answer to powering remote comms facilities is to just let the electric company bring in AC, to charge a battery which will last a short time, then disaster survivability was not the driving design goal for that selection. Possibly because their customers or their local government weren't demanding it, or weren't willing to pay enough for them to install suitably designed power distribution and backup. If you really care about building a reliable communications infrastructure, then you have at least two independent paths and sources for communications, and at least two independent paths and sources for power, to each major component of the system, so you provide your own power distribution, favoring reliability. That increases the price of the service, and if the consumer doesn't want it so badly that they'll pay significantly more, then it could be a waste, financially; most of the time, people won't notice extra fault tolerance measures versus a competitor's cheaper service that isn't so resilient in disasters. -- -JH From bill at herrin.us Sat Aug 4 11:56:06 2012 From: bill at herrin.us (William Herrin) Date: Sat, 4 Aug 2012 12:56:06 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <20120804160904.GC22887@hiwaay.net> References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <20120804160904.GC22887@hiwaay.net> Message-ID: On Sat, Aug 4, 2012 at 12:09 PM, Chris Adams wrote: > Well, in North Alabama in April 2011, we had to drive a lot more than 5 > miles (unless you left a 0 off the end). Across the Tennessee state > line (a good bit north of it) they had power, but they quickly ran out > of gas (and had a several hour wait in line to get what they had). I > was headed to Atlanta, and in 100 miles I drove past just one open gas > station (with very long lines) before I filled up in Georgia. 100 miles isn't a serious logistics problem with 500 gallons of fuel tank in the bed of a pickup truck. That buys you 8-12 hours for 100 fiber huts with $500 gasoline generators before you send the next crew for more. If it's the 2003 Northeast blackout or Hurricane Katrina then OK but short of that the LECs and CLECs and cable companies should be able keep the vast majority of their infrastructure online. Hell, local Verizon couldn't even keep the 911 center online. Both it and its backup collapsed. Got news for these folks: if you have cable on the poles spidering in to lots of homes and businesses you are a critical infrastructure provider and you need to act like it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nick at foobar.org Sat Aug 4 12:29:04 2012 From: nick at foobar.org (Nick Hilliard) Date: Sat, 04 Aug 2012 18:29:04 +0100 Subject: US House to ITU: Hands off the Internet In-Reply-To: References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> Message-ID: <501D5BE0.3090308@foobar.org> On 04/08/2012 16:55, Justin M. Streiner wrote: > On Sat, 4 Aug 2012, Jimmy Hess wrote: >>> "it is the "consistent and unequivocal policy of the United States to >>> promote a global Internet free from government control." >> >> Now if they would only practice what they preach..... > > It will be interesting to see how that statement gets (ab)used the next > time net neutrality, or legislation like SOPA/PIPA becomes a hot topic. I suspect they meant "a global Internet free from _other_ government control". Nick From owen at delong.com Sat Aug 4 12:31:02 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Aug 2012 10:31:02 -0700 Subject: IPv6 End User Fee In-Reply-To: <20120804100111.GS12615@leitl.org> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <15599C39-A2F0-41ED-9148-DFE42A971764@delong.com> <20120804100111.GS12615@leitl.org> Message-ID: On Aug 4, 2012, at 03:01 , Eugen Leitl wrote: > On Fri, Aug 03, 2012 at 08:31:06PM -0700, Owen DeLong wrote: > >> You MIGHT have paid some other organization for the privilege of transferring part or all of their registration rights to you. >> >> But in no case did you pay for the addresses themselves unless you are silly enough to think that a person can own an integer. > > IPv6 missed a great chance of doing away with all the > central waterfall trickle-down space distribution. > There was no need to fix what wasn't broken. > Luckily, /64 looks like large enough to bypass that > by offering address space sufficiently large while > co-existable with legacy addressing and routing. Why on earth would you be messing around within /64? It should be easy enough to get a /48 (it certainly is now). > I hope eventually somebody will start > tinkering with mesh radios which also have GPS > onboard (as most smartphones and tablets do). > 24 + 24 + 16 bits are just enough to represent > a decent-resolution WGS84 position fix. Plus, > GPS gives you a pretty accurate clock. That could be an interesting project. Limiting it to a /64 still doesn't make a lot of sense to me. Owen From ag4ve.us at gmail.com Sat Aug 4 12:49:05 2012 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 4 Aug 2012 13:49:05 -0400 Subject: US House to ITU: Hands off the Internet In-Reply-To: <501D5BE0.3090308@foobar.org> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <501D5BE0.3090308@foobar.org> Message-ID: On Sat, Aug 4, 2012 at 1:29 PM, Nick Hilliard wrote: > On 04/08/2012 16:55, Justin M. Streiner wrote: >> On Sat, 4 Aug 2012, Jimmy Hess wrote: >>>> "it is the "consistent and unequivocal policy of the United States to >>>> promote a global Internet free from government control." >>> >>> Now if they would only practice what they preach..... >> >> It will be interesting to see how that statement gets (ab)used the next >> time net neutrality, or legislation like SOPA/PIPA becomes a hot topic. > > I suspect they meant "a global Internet free from _other_ government control". > right and i don't think any government body expects to 'practice what they preach' (it might sound absurd, sarcastic, or ironical, but i am truly being serious here). it's more of a 'do what i say, not what i do' mentality. From eugen at leitl.org Sat Aug 4 14:41:05 2012 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 4 Aug 2012 21:41:05 +0200 Subject: IPv6 End User Fee In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <15599C39-A2F0-41ED-9148-DFE42A971764@delong.com> <20120804100111.GS12615@leitl.org> Message-ID: <20120804194105.GN12615@leitl.org> On Sat, Aug 04, 2012 at 10:31:02AM -0700, Owen DeLong wrote: > > IPv6 missed a great chance of doing away with all the > > central waterfall trickle-down space distribution. > > > > There was no need to fix what wasn't broken. Let's say I want to plunk down a zero-administration node somewhere, as an end user. The most natural approach is where addresses are derived from constraints, and address collisions are identical to physical space collisions. No two nodes can occupy the same space. By the time you're beyond these 2^24 lat/long resolution IPv6 is probably on its last legs anyway, and there's way to do renumbering with more bits, at the very least. > > Luckily, /64 looks like large enough to bypass that > > by offering address space sufficiently large while > > co-existable with legacy addressing and routing. > > Why on earth would you be messing around within /64? It should be easy enough to get a /48 (it certainly is now). It's a lowest common denominator, at least as long the ISPs are playing by the rules. If end users conspire to use a new addressing scheme bypassing the ISP infrastructure as the crow flies, a freely modyfiable address field within your ISP-assigned address space is the best label you can hope for. > > I hope eventually somebody will start > > tinkering with mesh radios which also have GPS > > onboard (as most smartphones and tablets do). > > 24 + 24 + 16 bits are just enough to represent > > a decent-resolution WGS84 position fix. Plus, > > GPS gives you a pretty accurate clock. > > That could be an interesting project. Limiting it to a /64 still doesn't make a lot of sense to me. I'm actually glad it's a /64. MAC space is a lot more cramped, and that information doesn't travel at all far. From jcurran at istaff.org Sat Aug 4 15:01:24 2012 From: jcurran at istaff.org (John Curran) Date: Sat, 4 Aug 2012 16:01:24 -0400 Subject: US House to ITU: Hands off the Internet In-Reply-To: <501D5BE0.3090308@foobar.org> References: <7FD2C7C4-0635-4FF2-A7A1-51B9B8534729@ianai.net> <501D5BE0.3090308@foobar.org> Message-ID: <127C3E33-926E-4337-8FDD-C86307E9D4C2@istaff.org> On Aug 4, 2012, at 1:29 PM, Nick Hilliard wrote: > On 04/08/2012 16:55, Justin M. Streiner wrote: >> On Sat, 4 Aug 2012, Jimmy Hess wrote: >>>> "it is the "consistent and unequivocal policy of the United States to >>>> promote a global Internet free from government control." >>> >>> Now if they would only practice what they preach..... >> >> It will be interesting to see how that statement gets (ab)used the next >> time net neutrality, or legislation like SOPA/PIPA becomes a hot topic. > > I suspect they meant "a global Internet free from _other_ government control". Actually, it is very likely that they truly mean "free of any government control", with the confusion coming from the idea that enforcing existing laws over the Internet (like copyright protection) isn't controlling the Internet but just routine law enforcement. Obviously, it is equally possible to view enforcing copyright protection as a form of Internet control and/or form of Internet censorship, so stating that governments shouldn't be controlling or censoring the Internet and then taking down hundreds of domain names is certainly going to cause confusion, if even the USG offers it as a perfectly logical and self-consistent position. FYI, /John Disclaimer: My views alone. Your mileage may vary. From sylvie at newnog.org Sat Aug 4 15:16:54 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Sat, 4 Aug 2012 16:16:54 -0400 Subject: [NANOG-announce] Announcing the October 2012 NANOG Elections Message-ID: *Hello NANOGers! This message is to encourage you, as a participant of this community, to become NANOG members and to consider standing for a leadership position at our upcoming October elections. The call for Board members nominations will be from August 20 to October 1 and for committee members from Sept 17 to October 23. We wanted to provide you now with the election process preview. It?s posted at http://www.nanog.org/governance/elections/2012elections/ and we?ll make announcements at every step. Why should you become a NANOG member? One Member = One Voter = One Eligible Candidate Candidate and Voter eligibility are opened to every ?member in good standing?. You may never have attended a conference but as an active reader and poster on our mailing lists, you contribute to the knowledge of this community. Becoming a NANOG member gives you the right to stand for a position and to vote in October. You can join at http://www.nanog.org/membership_main.html. What is expected of Committee Candidates? How many vacant positions? In Vancouver, we announced that the current leadership was documenting the roles, responsibilities and expectations placed on each position. We trust you will find the following useful. Candidates will be appointed Committee members by the newly elected Board next October. * 8 vacancies: Program Committee Member http://www.nanog.org/governance/PC_Responsibilities.pdf * 2 vacancies: Communications Committee Member http://www.nanog.org/governance/CC_Responsibilities.pdf * 2 vacancies: Development Committee Member http://www.nanog.org/governance/DC_Responsibilities.pdf What is expected of a Board Candidate? How many vacant positions? Read the Board Member Responsibilities and NANOG by-laws for a complete understanding of the expectations placed on Board Members. Board Member http://www.nanog.org/governance/BOD_Responsibilities.pdf NANOG By-laws http://www.nanog.org/governance/documents/By-Laws_20110104.pdf To ensure continuity on the Board, three seats out of six become open each year due to the expiration of 2-year terms. The Board members whose terms are expiring in October are: * Patrick Gilmore * Daniel Golding * Michael K. Smith Patrick has served two 2-year terms and cannot be considered for re-electionuntil October 2013 (one year leave). Daniel is completing the term vacated in June 2012 and he can stand for re-election. Michael is completing the term vacated in August 2011 and he can stand for re-election. How do you Nominate? You can self-nominate. You care about NANOG?s governance and want to take a turn at volunteering your time and expertise to help make it better. 1. Make sure you are a NANOG member in good standing 2. Submit your Declaration of Candidacy to elections at nanog.org. You can nominate others. 1. Send their contact information to elections at nanog.org 2. If they accept the nomination, they will be asked to become a NANOG member in good standing 3. They will have to submit their Declaration of Candidacy to elections at nanog.org. As NANOG continues to evolve, our Board and our Committees will continue to play an increasingly important role in our success. We thank you in advance for becoming NANOG members and taking an active part in our governance. Best regards, Sylvie, on behalf of the NANOG Board of Directors * -- Sylvie LaPerriere NANOG Board Chair - www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From joelja at bogus.com Sat Aug 4 19:02:19 2012 From: joelja at bogus.com (joel jaeggli) Date: Sat, 04 Aug 2012 17:02:19 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <007301cd71ee$4d4b2d60$e7e18820$@iname.com> Message-ID: <501DB80B.1040007@bogus.com> On 8/4/12 8:44 AM, Mike Jones wrote: > On 4 August 2012 04:07, Frank Bulk wrote: >> As someone else posted, many FTTH installations are centralized as much as >> possible to avoid having non-passive equipment in the plant, allowing for >> the practicality of onsite generators. That's what we do. But for those >> who have powered nodes in the field (distributed/tiered BPON or GPON >> configurations and cable plants), it's not realistic to keep them all >> powered. Despite what the DOT may be able to do. > > If only they had some kind of copper cabling running from some kind of > central location (like perhaps the same place the fiber runs to, I > imagine the same buildings that the old POTS lines ran to) that went > all the way out to the huts full of powered equipment (that would > likely be next to the old POTS junction boxes) that as a result of > their new fiber installs would have a few pairs unused, then they > could possibly have hooked those up as backup power when grid power > becomes unavailable for a large area (poor power distribution > efficiency would probably stop you wanting to power it that way all > the time). providing line voltage has a bit different current requirements than a remote ip dslam sitting in a hut. you're not powering something like: http://us.zyxel.com/Products/details.aspx?PC1IndexFlag=20040812100619&CategoryGroupNo=109D87CE-A152-4245-BE66-D455B07FE7A6 over 5000' of 24awg twisted pair. > > It's a shame that there isn't any such copper infrastructure owned by > those same companies already in place, but perhaps they could have > thrown an extra copper cable in to the middle of that fiber bundle at > the same time they were running it at negligible additional cost. > > - Mike > From owen at delong.com Sat Aug 4 20:53:48 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Aug 2012 18:53:48 -0700 Subject: IPv6 End User Fee In-Reply-To: <20120804194105.GN12615@leitl.org> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <15599C39-A2F0-41ED-9148-DFE42A971764@delong.com> <20120804100111.GS12615@leitl.org> <20120804194105.GN12615@leitl.org> Message-ID: <95CE094E-E517-4A08-BA9C-01F9F0701F9B@delong.com> On Aug 4, 2012, at 12:41 , Eugen Leitl wrote: > On Sat, Aug 04, 2012 at 10:31:02AM -0700, Owen DeLong wrote: > >>> IPv6 missed a great chance of doing away with all the >>> central waterfall trickle-down space distribution. >>> >> >> There was no need to fix what wasn't broken. > > Let's say I want to plunk down a zero-administration > node somewhere, as an end user. The most natural > approach is where addresses are derived from constraints, > and address collisions are identical to physical space > collisions. No two nodes can occupy the same space. > By the time you're beyond these 2^24 lat/long resolution > IPv6 is probably on its last legs anyway, and there's > way to do renumbering with more bits, at the very least. > This ignores the many many studies of the idea of geo-based addressing which have proven its unfeasibility as well as the fact that not everyone wants their address to reflect the exact coordinates of where the box is located. Also, any such scheme would depend on defining an arbitrary "minimum" sized box and ignores the possibility of needing many addresses for the same physical box containing multiple virtual nodes. It sounds great in theory until you actually compare it to the real world. IP addresses are not physical addresses and trying to correlate them only leads to artificial limitations and other problems. >>> Luckily, /64 looks like large enough to bypass that >>> by offering address space sufficiently large while >>> co-existable with legacy addressing and routing. >> >> Why on earth would you be messing around within /64? It should be easy enough to get a /48 (it certainly is now). > > It's a lowest common denominator, at least as long the > ISPs are playing by the rules. If end users conspire to use > a new addressing scheme bypassing the ISP infrastructure > as the crow flies, a freely modyfiable address field > within your ISP-assigned address space is the best label > you can hope for. > Uh, good luck with that. >>> I hope eventually somebody will start >>> tinkering with mesh radios which also have GPS >>> onboard (as most smartphones and tablets do). >>> 24 + 24 + 16 bits are just enough to represent >>> a decent-resolution WGS84 position fix. Plus, >>> GPS gives you a pretty accurate clock. >> >> That could be an interesting project. Limiting it to a /64 still doesn't make a lot of sense to me. > > I'm actually glad it's a /64. MAC space is a lot more cramped, > and that information doesn't travel at all far. You misunderstand... I'm suggesting a /48 (65,536 /64s), not a /80 (48 bits to mess around with). Owen From frnkblk at iname.com Sat Aug 4 21:17:25 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 4 Aug 2012 21:17:25 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> Message-ID: <00a501cd72b0$7462e060$5d28a120$@iname.com> Residences aren't critical infrastructure, no matter how angry the owners get. I can assure you that infrastructure that really *is* critical do have their own generators and receive priority attention from the service providers. Frank -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Saturday, August 04, 2012 11:56 AM To: Chris Adams; nanog at nanog.org Subject: Re: Verizon FiOS - is BGP an option? Got news for these folks: if you have cable on the poles spidering in to lots of homes and businesses you are a critical infrastructure provider and you need to act like it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Saturday, August 04, 2012 10:15 AM To: Chris Adams; nanog at nanog.org Subject: Re: Verizon FiOS - is BGP an option? Extended loss of power is a regular, high-probability threat. I think it reasonable to expect the local communications companies to be ready for it and capable of keeping the key infrastructure online. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nathan at atlasnetworks.us Sat Aug 4 21:26:52 2012 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 5 Aug 2012 02:26:52 +0000 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <00a501cd72b0$7462e060$5d28a120$@iname.com> References: <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <00a501cd72b0$7462e060$5d28a120$@iname.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C2889AF5BD5@EX-MB-1.corp.atlasnetworks.us> > Residences aren't critical infrastructure, no matter how angry the owners get. 911 access isn't a critical service? Fire and security panels aren't critical services? If basic life safety and property protection aren't critical services, I'm not sure what is. These are peoples' lives and families and homes. There is nothing - repeat, nothing - more important than that. It is absolutely a critical service. Nathan Eisenberg From alter3d at alter3d.ca Sat Aug 4 21:53:56 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sat, 04 Aug 2012 22:53:56 -0400 Subject: Verizon FiOS - is BGP an option? Message-ID: Considering that none of the services that can be dispatched by 911 are legally required to help you in most North American jurisdictions (i.e. if you call 911 and the police don't respond until they finish eating their box of donuts, they're not criminally or civilly liable), having working 911 services really doesn't guarantee you anything. Most security monitoring companies have contracts that are completely worthless and guarantee nothing as well. If you're depending on 911 for life safety and property protection, I'd recommend revising that plan to include a dog and/or gun. :-) - Pete Nathan Eisenberg wrote: >> Residences aren't critical infrastructure, no matter how angry the owners get. > >911 access isn't a critical service? Fire and security panels aren't critical services? > >If basic life safety and property protection aren't critical services, I'm not sure what is. These are peoples' lives and families and homes. There is nothing - repeat, nothing - more important than that. It is absolutely a critical service. > >Nathan Eisenberg > > From bill at herrin.us Sat Aug 4 23:14:42 2012 From: bill at herrin.us (William Herrin) Date: Sun, 5 Aug 2012 00:14:42 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <20120804160904.GC22887@hiwaay.net> Message-ID: On Sat, Aug 4, 2012 at 6:50 PM, Andy Koch wrote: > On Aug 4, 2012, at 11:56, William Herrin wrote: >> 100 miles isn't a serious logistics problem with 500 gallons of fuel >> tank in the bed of a pickup truck. That buys you 8-12 hours for 100 >> fiber huts with $500 gasoline generators before you send the next crew >> for more. > > Your expectations are way off here. With a 100 mile drive, even > if that is round trip mileage, you can expect that trip to exceed > 5 hours not including waiting in line to fuel up. Then when you > return, distribution can take well over 3 hours, meaning that > some locations will not get refueled before they run out. Then one group is on the gas run, fetching 500 gallons to a staging location while another group is on genset runs, topping the tanks of with the fetched gas. Or hey, if you're prepared then you have a contract in place with an oil company to divert one of the 9,000 gallon tank trucks from the non-functional local gas stations to your local distribution site. Then base your genset fueling runs from there. Few thousand bucks ahead of time to set up a box at the edge of one of your parking lots that can connect to the tanker's standard hose and pump gas. >> Hell, local Verizon couldn't even keep the 911 center online. Both it >> and its backup collapsed. > >So, rather than focus on repairing 911, you want these technicians >to drive for hours and distribute gasoline to keep your home data >service running? The E911 facility was supposed to be five nines. You don't get five nines with a focus on repair, you get it with prevention. This year Verizon'll achieve two nines. That's shameful. Shameful! I don't expect five nines from my residential Internet service. But I think two nines on the last mile cable and three nines on the aggregation system is a reasonable expectation for a primary first-world suburban communications service. It wasn't achieved. > Does the spider web of cables include power distribution? > If not, why the exception? If so, why not ostracize them > for failing to keep power to the "critical infrastructure" > in your neighborhood? Dominion can't seem to keep my local substation powered. Not my house per se, but the substation serving 611 power customers. They've missed 3 nines for at least 6 of the last 10 years without a single tree over the lines between me and the substation. And that's the last I'm going to say about it here because this isn't a forum for discussing the power companies' operational failures. It is, however, a forum for discussing network providers' operational failures. On Sat, Aug 4, 2012 at 10:26 PM, Nathan Eisenberg wrote: >> Residences aren't critical infrastructure, no matter how angry the owners get. > > 911 access isn't a critical service? Fire and security panels aren't critical services? > If basic life safety and property protection aren't critical services, I'm not sure what is. Whether each individual's residence contains critical infrastructure is a decision best left up to that individual. By necessity that makes the upstream aggregation components critical infrastructure. No different than it was for POTS 20 years ago. The Internet isn't just a toy any more. It's the primary communications channel in to many folks homes and well on its way to becoming the primary channel period. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Sat Aug 4 23:12:55 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Aug 2012 21:12:55 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: I've never met a dog properly trained in ACLS and I'm pretty sure that a gun isn't even useful for BLS. Owen On Aug 4, 2012, at 7:53 PM, Peter Kristolaitis wrote: > Considering that none of the services that can be dispatched by 911 are legally required to help you in most North American jurisdictions (i.e. if you call 911 and the police don't respond until they finish eating their box of donuts, they're not criminally or civilly liable), having working 911 services really doesn't guarantee you anything. Most security monitoring companies have contracts that are completely worthless and guarantee nothing as well. > > If you're depending on 911 for life safety and property protection, I'd recommend revising that plan to include a dog and/or gun. :-) > > - Pete > > > > Nathan Eisenberg wrote: > >>> Residences aren't critical infrastructure, no matter how angry the owners get. >> >> 911 access isn't a critical service? Fire and security panels aren't critical services? >> >> If basic life safety and property protection aren't critical services, I'm not sure what is. These are peoples' lives and families and homes. There is nothing - repeat, nothing - more important than that. It is absolutely a critical service. >> >> Nathan Eisenberg >> >> From bill at herrin.us Sat Aug 4 23:24:48 2012 From: bill at herrin.us (William Herrin) Date: Sun, 5 Aug 2012 00:24:48 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <007301cd71ee$4d4b2d60$e7e18820$@iname.com> Message-ID: On Sat, Aug 4, 2012 at 11:44 AM, Mike Jones wrote: > If only they had some kind of copper cabling running from some kind of > central location [...] (poor power distribution > efficiency would probably stop you wanting to power it that way all > the time). I imagine the problem would be safety and regulation rather than efficiency. Send a few amps as a couple thousand vdc over a 14 awg pair and you'll have no trouble efficiently powering the fiber hut a few thousand meters away. But the telco's attachment on the pole is relatively low to the ground. Semis have been known to take out the phone cable exiting parking lots when it sags for some reason. Having a few thousand volts in that cable might make the regulators nervous. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From eugen at leitl.org Sun Aug 5 05:22:32 2012 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 5 Aug 2012 12:22:32 +0200 Subject: IPv6 End User Fee In-Reply-To: <95CE094E-E517-4A08-BA9C-01F9F0701F9B@delong.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> <15599C39-A2F0-41ED-9148-DFE42A971764@delong.com> <20120804100111.GS12615@leitl.org> <20120804194105.GN12615@leitl.org> <95CE094E-E517-4A08-BA9C-01F9F0701F9B@delong.com> Message-ID: <20120805102232.GC12615@leitl.org> On Sat, Aug 04, 2012 at 06:53:48PM -0700, Owen DeLong wrote: > This ignores the many many studies of the idea of geo-based > addressing which have proven its unfeasibility as well as the I disagree that the studies have looked at the problem space from the right angle. > fact that not everyone wants their address to reflect the exact > coordinates of where the box is located. Routing efficiency and anonymity are mutually exclusive. Apart from geoip databases triangulation via time of flight will nail you down in space in any case. Anonymization should be a function of an extra layer, just as Tor and I2P etc. are doing it for TCP/IP. > Also, any such scheme would depend on defining an arbitrary > "minimum" sized box and ignores the possibility of needing > many addresses for the same physical box containing multiple > virtual nodes. You cannot have two physical switches occupying the same space. 128 bits is quite enough to physically address each cubic micron in 1/3rd of Earth volume. > It sounds great in theory until you actually compare it to the > real world. > > IP addresses are not physical addresses and trying to /64 is enough to abuse parts of IPv6 to encode physical coordinates. > correlate them only leads to artificial limitations and other > problems. Interesting. I see the current IPv4/IPv6 model full of artificial limitations that go away if you remove the centralistic governance model. > >>> Luckily, /64 looks like large enough to bypass that > >>> by offering address space sufficiently large while > >>> co-existable with legacy addressing and routing. > >> > >> Why on earth would you be messing around within /64? It should be easy enough to get a /48 (it certainly is now). > > > > It's a lowest common denominator, at least as long the > > ISPs are playing by the rules. If end users conspire to use > > a new addressing scheme bypassing the ISP infrastructure > > as the crow flies, a freely modyfiable address field > > within your ISP-assigned address space is the best label > > you can hope for. > > > > Uh, good luck with that. Do you see problems with this scheme? There's considerable interest and momentum in end user owned routing infrastructure, including wireless ad hoc meshes across urban areas. > >>> I hope eventually somebody will start > >>> tinkering with mesh radios which also have GPS > >>> onboard (as most smartphones and tablets do). > >>> 24 + 24 + 16 bits are just enough to represent > >>> a decent-resolution WGS84 position fix. Plus, > >>> GPS gives you a pretty accurate clock. > >> > >> That could be an interesting project. Limiting it to a /64 still doesn't make a lot of sense to me. > > > > I'm actually glad it's a /64. MAC space is a lot more cramped, > > and that information doesn't travel at all far. > > > You misunderstand... I'm suggesting a /48 (65,536 /64s), not > a /80 (48 bits to mess around with). You can't have the same /48 getting routed to random end users all over the world. But each of these users can use the local /64 as scratch space that will be preserved as it travels across IPv6 Internet. From alter3d at alter3d.ca Sun Aug 5 07:50:21 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sun, 05 Aug 2012 08:50:21 -0400 Subject: Verizon FiOS - is BGP an option? Message-ID: <491h8dkclrcroqrkb7sw58yg.1344169703914@email.android.com> My point is more along the line of if you're depending on a service which provides only best-effort on uptime (as Bill Herrin mentioned, some providers can barely manage 2 nines of 911 uptime) and to which you're connected by a single, fault-prone connection, and which provides no guarantee of service even if you CAN contact them, calling it "critical" is kind of a joke, and you'd probably get laughed at by a risk analyst. If you're serious about protecting health and home, you'd better have some other plan in place that doesn't have a ridiculous number of single points of failure. Pete Owen DeLong wrote: >I've never met a dog properly trained in ACLS and I'm pretty sure that a gun isn't even useful for BLS. > >Owen > >On Aug 4, 2012, at 7:53 PM, Peter Kristolaitis wrote: > >> Considering that none of the services that can be dispatched by 911 are legally required to help you in most North American jurisdictions (i.e. if you call 911 and the police don't respond until they finish eating their box of donuts, they're not criminally or civilly liable), having working 911 services really doesn't guarantee you anything. Most security monitoring companies have contracts that are completely worthless and guarantee nothing as well. >> >> If you're depending on 911 for life safety and property protection, I'd recommend revising that plan to include a dog and/or gun. :-) >> >> - Pete >> >> >> >> Nathan Eisenberg wrote: >> >>>> Residences aren't critical infrastructure, no matter how angry the owners get. >>> >>> 911 access isn't a critical service? Fire and security panels aren't critical services? >>> >>> If basic life safety and property protection aren't critical services, I'm not sure what is. These are peoples' lives and families and homes. There is nothing - repeat, nothing - more important than that. It is absolutely a critical service. >>> >>> Nathan Eisenberg >>> >>> > From johnl at iecc.com Sun Aug 5 11:00:18 2012 From: johnl at iecc.com (John Levine) Date: 5 Aug 2012 16:00:18 -0000 Subject: IPv6 End User Fee In-Reply-To: <20120805102232.GC12615@leitl.org> Message-ID: <20120805160018.91966.qmail@joyce.lan> >Do you see problems with this scheme? There's considerable >interest and momentum in end user owned routing infrastructure, >including wireless ad hoc meshes across urban areas. I've seen remarkably little overlap between the people that think ad hoc meshes are a fabulous liberating technology and the people who understand how they work and what their limitatations are. As a way to bring some sort of service to unserved areas, they're interesting. As a substitute for a real network, they're not. R's, John From eugen at leitl.org Sun Aug 5 11:30:39 2012 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 5 Aug 2012 18:30:39 +0200 Subject: IPv6 End User Fee In-Reply-To: <20120805160018.91966.qmail@joyce.lan> References: <20120805102232.GC12615@leitl.org> <20120805160018.91966.qmail@joyce.lan> Message-ID: <20120805163039.GN12615@leitl.org> On Sun, Aug 05, 2012 at 04:00:18PM -0000, John Levine wrote: > >Do you see problems with this scheme? There's considerable > >interest and momentum in end user owned routing infrastructure, > >including wireless ad hoc meshes across urban areas. > > I've seen remarkably little overlap between the people that think ad > hoc meshes are a fabulous liberating technology and the people who > understand how they work and what their limitatations are. Absolutely accurate observation. > As a way to bring some sort of service to unserved areas, they're > interesting. As a substitute for a real network, they're not. By its nature, the wireless ad hoc are at best good for more or less understandable audio calls in a tight codec or text message (or email) delivery. Even so, in current systems the scaling is limited by admin traffic chatter. The interesting part is how well would the newer protocols work if the wireless links were substituted by reliable >1 GBit/s connections. From mysidia at gmail.com Sun Aug 5 13:33:01 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 5 Aug 2012 13:33:01 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <491h8dkclrcroqrkb7sw58yg.1344169703914@email.android.com> References: <491h8dkclrcroqrkb7sw58yg.1344169703914@email.android.com> Message-ID: On 8/5/12, Peter Kristolaitis wrote: > My point is more along the line of if you're depending on a service which > provides only best-effort on uptime (as Bill Herrin mentioned, some > providers can barely manage 2 nines of 911 uptime) and to which you're > connected by a single, fault-prone connection, and which provides no > guarantee of service even if you CAN contact them, calling it "critical" is > kind of a joke, and you'd probably get laughed at by a risk analyst. If I've yet to hear of a successful lawsuit bringing a victim back to life. Criticality is defined based on the impact and importance of the service not working correctly, not on its actual lack of fault tolerance mechanisms. The lack of proper reliability, if/where that's the case, is a regulatory issue that should be addressed by citizens contacting their government, and entering complaints with their elected reps. > you're serious about protecting health and home, you'd better have some > other plan in place that doesn't have a ridiculous number of single points > of failure. Plan away, there are still situations where assistance would be absolutely essential. Your example of "add a Dog and Gun" to the plan may help in case of "Police not available"; it won't help against multiple armed adversaries carrying drugged meat to seduce dogs, who just want to kill without regard. It won't help in case of no response to call for Fire department or Medical. Dogs and Guns are also dangerous implements, require skills to operate and a great deal of care and mainteinance, there are more people accidentally injured or killed by them, or discharging them illegally, or their guns getting stolen and turned against them, than successfully using them in a legal tactically appropriate way for self-defense. > Pete -- -JH From owen at delong.com Sun Aug 5 13:52:24 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Aug 2012 11:52:24 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <491h8dkclrcroqrkb7sw58yg.1344169703914@email.android.com> References: <491h8dkclrcroqrkb7sw58yg.1344169703914@email.android.com> Message-ID: <2D0767DB-CABE-4B04-94DD-1F5C5F916314@delong.com> Agreed. My point was that the police have the least of all emergency services to do with protection of life and property and that a gun or a dog only helps you with the functions that they can perform. People depend on 911 for much more than just police and if you're trying to come up with an alternate plan, it's much more important to address the questions of emergency medical services and fire protection than the relatively lower risk of threats from an intruder. Owen On Aug 5, 2012, at 05:50 , Peter Kristolaitis wrote: > My point is more along the line of if you're depending on a service which provides only best-effort on uptime (as Bill Herrin mentioned, some providers can barely manage 2 nines of 911 uptime) and to which you're connected by a single, fault-prone connection, and which provides no guarantee of service even if you CAN contact them, calling it "critical" is kind of a joke, and you'd probably get laughed at by a risk analyst. If you're serious about protecting health and home, you'd better have some other plan in place that doesn't have a ridiculous number of single points of failure. > > Pete > > > Owen DeLong wrote: > >> I've never met a dog properly trained in ACLS and I'm pretty sure that a gun isn't even useful for BLS. >> >> Owen >> >> On Aug 4, 2012, at 7:53 PM, Peter Kristolaitis wrote: >> >>> Considering that none of the services that can be dispatched by 911 are legally required to help you in most North American jurisdictions (i.e. if you call 911 and the police don't respond until they finish eating their box of donuts, they're not criminally or civilly liable), having working 911 services really doesn't guarantee you anything. Most security monitoring companies have contracts that are completely worthless and guarantee nothing as well. >>> >>> If you're depending on 911 for life safety and property protection, I'd recommend revising that plan to include a dog and/or gun. :-) >>> >>> - Pete >>> >>> >>> >>> Nathan Eisenberg wrote: >>> >>>>> Residences aren't critical infrastructure, no matter how angry the owners get. >>>> >>>> 911 access isn't a critical service? Fire and security panels aren't critical services? >>>> >>>> If basic life safety and property protection aren't critical services, I'm not sure what is. These are peoples' lives and families and homes. There is nothing - repeat, nothing - more important than that. It is absolutely a critical service. >>>> >>>> Nathan Eisenberg >>>> >>>> >> From jhellenthal at dataix.net Sun Aug 5 18:08:56 2012 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sun, 5 Aug 2012 19:08:56 -0400 Subject: NFSen plugin - ddd In-Reply-To: <49f9d2ec16de2c67b51a0229dcf18510@localhost> References: <49f9d2ec16de2c67b51a0229dcf18510@localhost> Message-ID: <20120805230856.GA55456@DataIX.net> Don't know if you ever recieved a reply for this but this is the best I have come up with to get more eyes on it. http://sourceforge.net/apps/trac/nfsen-plugins/wiki/RequestPlugin I have not submitted a request for it but if you happen to come accross this plugin, I would be interested. On Fri, Aug 03, 2012 at 01:55:21PM +1000, Andrew Jones wrote: > Hi All, > Does anyone have a copy of the DDoS detection plugin for NFSen called ddd > that they could send to me? > According to a blog article [1] I read, it used to be available at [2]. > It's not there, and I haven't had any luck trying to track it down the > usual ways. If anyone is able to provide a copy, I'd appreciate it. > Thanks, > Jonesy > > > [1] http://www.ccieflyer.com/2010-01-JasonRowley.php > [2] http://www.synacknetworks.com/ddd/ddd.zip -- - (2^(N-1)) JJH48-ARIN -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From frnkblk at iname.com Sun Aug 5 20:55:30 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 5 Aug 2012 20:55:30 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C2889AF5BD5@EX-MB-1.corp.atlasnetworks.us> References: <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <00a501cd72b0$7462e060$5d28a120$@iname.com> <8C26A4FDAE599041A13EB499117D3C2889AF5BD5@EX-MB-1.corp.atlasnetworks.us> Message-ID: <00ab01cd7376$8ee4b1e0$acae15a0$@iname.com> My apologies, I think we crossed wires here. This thread included a discussion of continual residential Internet access in an extended power outage. That's the topic I was responding to, not E911. Frank -----Original Message----- From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us] Sent: Saturday, August 04, 2012 9:27 PM To: nanog at nanog.org Subject: RE: Verizon FiOS - is BGP an option? > Residences aren't critical infrastructure, no matter how angry the owners get. 911 access isn't a critical service? Fire and security panels aren't critical services? If basic life safety and property protection aren't critical services, I'm not sure what is. These are peoples' lives and families and homes. There is nothing - repeat, nothing - more important than that. It is absolutely a critical service. Nathan Eisenberg From frnkblk at iname.com Sun Aug 5 21:41:15 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 5 Aug 2012 21:41:15 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <20120804160904.GC22887@hiwaay.net> Message-ID: <00b201cd737c$f3431090$d9c931b0$@iname.com> I think the term "critical" is being used in different senses in this discussion. Are people's lives critical? Yes, but the regulations for wired and wireless infrastructure don't require service providers to expend any and all costs to maintain connectivity. And we don't have ambulances and fire trucks at every corner and hospitals in every subdivision. Despite the almost incalculable value of life, there are still limitations on all the services provided to residences. Would I like to have the same uptime at my home as we have in the CO? or data center? Sure, but collectively we aren't willing, nay, able, to pay that price. Frank -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Saturday, August 04, 2012 11:15 PM To: Andy Koch Cc: nanog at nanog.org Subject: Re: Verizon FiOS - is BGP an option? On Sat, Aug 4, 2012 at 10:26 PM, Nathan Eisenberg wrote: >> Residences aren't critical infrastructure, no matter how angry the owners get. > > 911 access isn't a critical service? Fire and security panels aren't critical services? > If basic life safety and property protection aren't critical services, I'm not sure what is. Whether each individual's residence contains critical infrastructure is a decision best left up to that individual. By necessity that makes the upstream aggregation components critical infrastructure. No different than it was for POTS 20 years ago. The Internet isn't just a toy any more. It's the primary communications channel in to many folks homes and well on its way to becoming the primary channel period. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sun Aug 5 23:19:28 2012 From: bill at herrin.us (William Herrin) Date: Mon, 6 Aug 2012 00:19:28 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <00b201cd737c$f3431090$d9c931b0$@iname.com> References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <20120804160904.GC22887@hiwaay.net> <00b201cd737c$f3431090$d9c931b0$@iname.com> Message-ID: On Sun, Aug 5, 2012 at 10:41 PM, Frank Bulk wrote: > Would I like to have the same uptime > at my home as we have in the CO? or data center? Sure, but collectively we > aren't willing, nay, able, to pay that price. We paid the price for 3-nines on the home comm service 20 years ago. Did customer expectations change? Or is the LEC just trying to pull a fast one since the tech isn't exactly the same? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Sun Aug 5 23:35:33 2012 From: joelja at bogus.com (joel jaeggli) Date: Sun, 05 Aug 2012 21:35:33 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <20120804160904.GC22887@hiwaay.net> <00b201cd737c$f3431090$d9c931b0$@iname.com> Message-ID: <501F4995.5020400@bogus.com> On 8/5/12 9:19 PM, William Herrin wrote: > On Sun, Aug 5, 2012 at 10:41 PM, Frank Bulk wrote: >> Would I like to have the same uptime >> at my home as we have in the CO? or data center? Sure, but collectively we >> aren't willing, nay, able, to pay that price. > We paid the price for 3-nines on the home comm service 20 years ago. > Did customer expectations change? Given that a growing number of them don't even have residential voice service that seems like a valid assumption. > Or is the LEC just trying to pull a > fast one since the tech isn't exactly the same? The customer with naked dsl or cable without voice is not buying telephony from the lec anyway. If all the members of the household have the same cellular provider I guess they share fate. > Regards, > Bill Herrin > > From ralphw at interworld.net Sun Aug 5 23:53:38 2012 From: ralphw at interworld.net (Ralph E. Whitmore, III) Date: Mon, 6 Aug 2012 04:53:38 +0000 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <00b201cd737c$f3431090$d9c931b0$@iname.com> References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <20120804160904.GC22887@hiwaay.net> <00b201cd737c$f3431090$d9c931b0$@iname.com> Message-ID: <116ED2ECE3E1764BB9777152785AB9E80CE855FC@EXCH2010.torrance.interworld.net> What I think most people are objecting to is that most of the issue with maintain service is not related to technical capabilities, but related to the cost of providing these support services impacting the profit margins of the large monopolistic carriers. Verizon with their FIOS offerings, at least in my area is CO based and all optical, so all I have to provide is power to my own FIOS terminal which is easy to do, floated on batteries (not the POS that VZ provided but a real battery bank) and I stay online. We have been through 10 outages at least 10 hours in duration and one 3 day outage all courtesy of SCE who can't figure out how to replace the 57 year old wires that keep breaking from corrosion here in So. Calif. As a subscriber, I paid for the copper Wire that VZ installed, I paid for the Copper that Edison installed, I pay to maintain both of these services on a 7x24x365 basis. And each and every month, SCE and VZ take a mandatory deduction out of my bill specifically to replace the copper every 50 years (the design life of the infrastructure). Edison squanders that money and just patches the infrastructure with no regard for the customers, and VZ replaces the copper with FIOS so they don't have to allow any competition from anyone else and demos the copper when they are done so no one else can use it. All of these companies fail to understand that they were granted a license and handed the keys to provide a public service and we expect them to perform that job rain or shine 7x24x365. Hurricanes (while not a problem where I am) are a known problem in many parts of the company and it is their job to maintain service despite the hurricanes. These fiber huts/RSU's were installed to minimize VZ's (insert your favorite carrier here) cost of maintenance for their network . This way, they can increase their profits by laying off more workers and hiring more subcontractors. So be it, that is their business model. What people/PUC/ Regulatory bodies fail to follow up on is that just because they are allowed to install Fiber Huts/RSU's the customers should expect the same level of service and redundancy that is provided by a brick and mortar CO built to the ATT/Bellcore standards for stability and reliability. I am all for the carriers pushing the edge closer to the customers, but it should not be allowed to occur at a substandard level. They certainly aren't offering a discount for substandard service received by some. My customers get 99.999% reliability from my infrastructure, I expect the carriers to do at least as well, obviously that doesn't happen. All my Roadside cabinets have a DC plant that is engineered to hold the facility for at least 18 hours based on the equipment in the box. All my facilities have an external Transfer switch and a generator plug. A single 5kw generator, with one cable and padlock, with one tank of fuel (generally propane or diesel)(about 5 gallons) will run the hut for 8-10 hours, fully recharge the DC plant inside buying you another 18 hours on battery (therefore 28 additional hours before fuel is needed) and to boot have electronic monitoring to tell me if there is another AC failure of the generator during that 8-10 hours. One contractor, god forbid we wouldn't do this with actual employees of the company, with a pickup truck and a small trailer should be able to support between 12-20 Fiber Huts /RSU's in a single shift. If your site is bigger than a 5KW site then you should have generator backup onsite in the first place. If I can do this Verizon/ATT/Centurylink should have no trouble supporting their facilities in a similar fashion. I am a little dinky company with 12 employees, but Verizon( your carrier name here) If you want to use Wisper Watt 25KW generators, more power to you, they will just pass the costs on to us anyways in the next rate hike. The argument about lack of fuel availability is total bunk as well as I can't believe that any carrier doesn't already have 1000's of gallons onsite already to support their CO's, trucks, ect. if you need more you can order a 5000gallon tank like everyone else in the real world does, you can probably have it delivered tomorrow afternoon if you place the order tomorrow morning before noon. Lack of power at an Fiber hut/RSU is negligence at best on a carriers part, not an unsolvable technical problem My uncle who retired from Bell Atlantic/VZ after 30 years was in a rural area of Virginia and now works as a contractor for emergency restoration after storms. He was called in to work on Storm restoration he along with 20 other crews, were told report to the staging yard and wait for an assignment. It took three days to get to the staging area, They waited 4 days in the yard before being assigned work and was then told that they couldn't work more than 12 hours in a day, because VZ would only pay for a max of 4 hours OT for any personnel in a 24 hour period. They worked for 4 days and were then sent home as they were no longer needed. To the best of my recollection people were without service for weeks if not months. The safety wackos in the world will say well we don't want to tax our employees and more than 12 hours isn't safe. Ok, I will not argue the validity of their argument, personally I disagree with it, but this is an emergency response not a shareholders meeting, but sending the crews home weeks before all service is restored doesn't resonate well. IMHO Restoration was not about serving the people who were out of service, but rather spending at little as they could get away with without regard for the people who pay for the infrastructure and pay their bills. While we are at it, my uncle installed the RSU he is serviced from at his house before he retired from Bell Atlantic/VZ, they engineered only 4 hours of battery backup for their site near his house, the fiber hut/RSU is approx. 8'x8'x5' and it has only 4 -105AH batteries installed in it, there are three vacant shelves for more batteries and one totally vacant compartment left in the cabinet for battery expansion. Given the rural nature of his service RSU, the nearest stocking yard for VZ is better than an hour's drive from his RSU. Given the Union contract gives the workers 2 hours to show up at the yard from the time they are contacted ( which could take hours to do in the first place if his RSU is down) there is almost no way that you can callout a tech and make it to the site before the battery back is exhausted and Dominion Power is highly un-likely to arrive onsite in less than 12 hours from the time of call. So this site is doomed to go down from the start. A single house, my house, your house, despite what we think are not critical infrastructure to the carriers, but the fiber huts that service them certainly is and needs to be supported better than they are now. Back to the original topic, BGP works great over FIOS if you have a business account with static IP's and a Cooperative Colo. I have IPv4 and IPv6 running at my house and office (we microwave the Home's business FIOS to the office) through a GRE tunnel. It's the cheapest 35x35Mb connection around for about $200.00 with 32 static IP's around TWC wants about $2k for the same service. It took a little bit of fiddling to get the MTU right across the tunnel (ip tcp adjust-mss is your friend) I could upgrade the service for another $100.00 to 150Mb x 65Mb, but the wireless link won't support that without a large expenditure and for 12 people it's not needed. Boy that was a lot, glad I had time on a Sunday night to write this after fueling my generator. Ralph -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, August 05, 2012 7:41 PM To: 'William Herrin'; Andy Koch Cc: nanog at nanog.org Subject: RE: Verizon FiOS - is BGP an option? I think the term "critical" is being used in different senses in this discussion. Are people's lives critical? Yes, but the regulations for wired and wireless infrastructure don't require service providers to expend any and all costs to maintain connectivity. And we don't have ambulances and fire trucks at every corner and hospitals in every subdivision. Despite the almost incalculable value of life, there are still limitations on all the services provided to residences. Would I like to have the same uptime at my home as we have in the CO? or data center? Sure, but collectively we aren't willing, nay, able, to pay that price. Frank -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Saturday, August 04, 2012 11:15 PM To: Andy Koch Cc: nanog at nanog.org Subject: Re: Verizon FiOS - is BGP an option? On Sat, Aug 4, 2012 at 10:26 PM, Nathan Eisenberg wrote: >> Residences aren't critical infrastructure, no matter how angry the >> owners get. > > 911 access isn't a critical service? Fire and security panels aren't critical services? > If basic life safety and property protection aren't critical services, > I'm not sure what is. Whether each individual's residence contains critical infrastructure is a decision best left up to that individual. By necessity that makes the upstream aggregation components critical infrastructure. No different than it was for POTS 20 years ago. The Internet isn't just a toy any more. It's the primary communications channel in to many folks homes and well on its way to becoming the primary channel period. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From j at arpa.com Mon Aug 6 01:49:07 2012 From: j at arpa.com (jamie rishaw) Date: Mon, 6 Aug 2012 01:49:07 -0500 Subject: BGPttH. Neustar can do it, why can't we? Message-ID: discuss. From mail at danrl.de Mon Aug 6 02:18:56 2012 From: mail at danrl.de (Dan Luedtke) Date: Mon, 06 Aug 2012 09:18:56 +0200 Subject: IPv6 End User Fee In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B017C12@ocsbs.ocosa.com> Message-ID: <1344237536.5128.3.camel@localhost> On Fri, 2012-08-03 at 14:22 -0500, Otis L. Surratt, Jr. wrote: > 1. How are you making up loss of revenue on IPv4 assignments? By using legacy IP only were it is necessary. This way I have to support only one stack (IPv6), that saves me money. Regards. Dan -- Dan Luedtke http://www.danrl.de From bill at herrin.us Mon Aug 6 08:07:00 2012 From: bill at herrin.us (William Herrin) Date: Mon, 6 Aug 2012 09:07:00 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: On Mon, Aug 6, 2012 at 2:49 AM, jamie rishaw wrote: > discuss. Commodity service from a commodity provider. As much as I'd love for Verizon to offer BGP directly over FIOS there are fewer than 40,000 customers worldwide for such a service. As long as they maintain sufficient network neutrality to get high speed tunnel service with someone and run BGP over the tunnel their behavior is not outrageous. To facilitate this and all the folks with custom needs, a wireline provider should have a choice between unbundling and open settlement-free peering. Mandatory to do at least one. But that's a whole other can of worms. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Mon Aug 6 09:08:45 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 6 Aug 2012 10:08:45 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: On Mon, Aug 6, 2012 at 9:07 AM, William Herrin wrote: > As much as I'd love for > Verizon to offer BGP directly over FIOS there are fewer than 40,000 I'm curious as to your number... where is that from? Marhsall had noted a number of 'small businesses' in the US at ~1.4m as of ~2006ish? I'd think that there are many use-cases where BGP is useful for end users of FIOS, turning out a 'business' class of service without BGP seems like a less useful 'business' solution (especially where the sla isn't really much better than the consumer solution). -chris From livio.zanol.puppim at gmail.com Mon Aug 6 09:10:32 2012 From: livio.zanol.puppim at gmail.com (Livio Zanol Puppim) Date: Mon, 6 Aug 2012 11:10:32 -0300 Subject: IETF contacts? - Fwd: Reference to historic or obsolated RFCs Message-ID: Hello guys, I've sent the e-mail below to IETF, but I couldn't find a contact e-mail to address this kind of subject in IETF site. Does anybody knows which e-mail to send this? The contact page from IETF website: http://www.ietf.org/contact-the-ietf.html ---------- Forwarded message ---------- From: Livio Zanol Puppim Date: 2012/8/6 Subject: Reference to historic or obsolated RFCs To: ietf-info at ietf.org, ietf-action at ietf.org Hello, I don't know which contact to send this e-mail, so I'm copying the INFO and ACTION e-mail... If these are the wrong contact, can you please point me the correct e-mail? Reading the *RFC 5375* I've found references to some RFCs that are considered Historic, or have been updated. In some cases, this can lead to a misunderstand of a a section in a RFC. For example: The* RFC 5375* in section *B.2.2* states that we should avoid using /127 IPv6 prefix, but* RFC 6164* clearly says that we can use /127 prefix for Inter-Router links. In fact, the *RFC 6547*, moves the *RFC 3627*(referenced by the * RFC 5375* in the above section) to Historic status. If my point of view is indeed correct, I think that everytime a new RFC is published that proposes an *Update* to another RFC, or *Obsoletes* another RFC or moves a RFC to *Historic *status, the team responsible for it's creation needs to read every reference to that RFC and request changes in order to avoid this kind of misunderstanding. This is very important to guys like me, that only reads the RFCs. the section from RFC 5375 http://tools.ietf.org/html/rfc5375#appendix-B.2.2 " B.2.2 . /127 Addresses The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 [RFC3021 ], is not valid and should be strongly discouraged as documented in RFC 3627 [RFC3627 ]. " -- []'s L?vio Zanol Puppim -- []'s L?vio Zanol Puppim From jabley at hopcount.ca Mon Aug 6 09:16:06 2012 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 6 Aug 2012 10:16:06 -0400 Subject: IETF contacts? - Fwd: Reference to historic or obsolated RFCs In-Reply-To: References: Message-ID: <38804605-6816-4909-A254-1517D3501E5D@hopcount.ca> On 2012-08-06, at 10:10, Livio Zanol Puppim wrote: > I've sent the e-mail below to IETF, but I couldn't find a contact e-mail to > address this kind of subject in IETF site. Does anybody knows which e-mail > to send this? http://www.rfc-editor.org/rfcfaq.html https://www.rfc-editor.org/mailman/listinfo/rfc-interest Joe From bicknell at ufp.org Mon Aug 6 09:21:24 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 6 Aug 2012 07:21:24 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: <20120806142124.GA56428@ussenterprise.ufp.org> In a message written on Mon, Aug 06, 2012 at 01:49:07AM -0500, jamie rishaw wrote: > discuss. It's a short sighted result created by the lack of competition. IP access is a commodity service, with thin margins that will only get thinner. Right now those margins are being propped up in many locations by monopoly or near-monopoly status, which creates a situation where companies neither need to compete on features and service quality nor do they need to turn to those areas to maintain a profit. If there was meaningful competition, the margin on raw IP access would decline and companies would have to turn to value-add services to maintain a profit margin. From the simple up-sell of a static IP address that some do today, to a fee for BGP, a fee for DDOS mitigation, and so on. These are all things it's not uncommon to see when buying service in carrier netural colos where there is competition. There is no technological problem here. BGP to the end user has a cost. The current business climate is causing people to cut all possible costs and offering no incentive to innvovate and up-charge. Which leads to an interesting question. If on top of your $100/month "business class Internet" the provider were to charge $50/month for "BGP Access" to cover their costs of having a human configure the session, larger access gear to handle the routes, and larger backbone gear to deal with a larger routing table, would you still be as gung ho about BGP to the business? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mansaxel at besserwisser.org Mon Aug 6 09:23:38 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 6 Aug 2012 16:23:38 +0200 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: <20120806142337.GD9524@besserwisser.org> Subject: Re: BGPttH. Neustar can do it, why can't we? Date: Mon, Aug 06, 2012 at 10:08:45AM -0400 Quoting Christopher Morrow (morrowc.lists at gmail.com): > On Mon, Aug 6, 2012 at 9:07 AM, William Herrin wrote: > > As much as I'd love for > > Verizon to offer BGP directly over FIOS there are fewer than 40,000 > > I'm curious as to your number... where is that from? AS numbers used to be 16-bit. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I don't believe there really IS a GAS SHORTAGE.. I think it's all just a BIG HOAX on the part of the plastic sign salesmen -- to sell more numbers!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From livio.zanol.puppim at gmail.com Mon Aug 6 09:24:23 2012 From: livio.zanol.puppim at gmail.com (Livio Zanol Puppim) Date: Mon, 6 Aug 2012 11:24:23 -0300 Subject: IETF contacts? - Fwd: Reference to historic or obsolated RFCs In-Reply-To: <38804605-6816-4909-A254-1517D3501E5D@hopcount.ca> References: <38804605-6816-4909-A254-1517D3501E5D@hopcount.ca> Message-ID: Thanks! :) 2012/8/6 Joe Abley > > On 2012-08-06, at 10:10, Livio Zanol Puppim > wrote: > > > I've sent the e-mail below to IETF, but I couldn't find a contact e-mail > to > > address this kind of subject in IETF site. Does anybody knows which > e-mail > > to send this? > > http://www.rfc-editor.org/rfcfaq.html > https://www.rfc-editor.org/mailman/listinfo/rfc-interest > > > Joe > > -- []'s L?vio Zanol Puppim From bill at herrin.us Mon Aug 6 09:27:21 2012 From: bill at herrin.us (William Herrin) Date: Mon, 6 Aug 2012 10:27:21 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow wrote: > On Mon, Aug 6, 2012 at 9:07 AM, William Herrin wrote: >> As much as I'd love for >> Verizon to offer BGP directly over FIOS there are fewer than 40,000 > > I'm curious as to your number... where is that from? > Marhsall had noted a number of 'small businesses' in the US at ~1.4m > as of ~2006ish? Hi Chris, Lacking any reason to believe otherwise, I estimate the number of BGP users at reasonably close to the number of autonomous systems in the Internet BGP table. Technically that doesn't have to be true... but given the debugging nuissance associated with private AS numbers and the trivial ease and cost with which an AS is registered it seems likely to me. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Aug 6 09:31:11 2012 From: bill at herrin.us (William Herrin) Date: Mon, 6 Aug 2012 10:31:11 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <20120806142124.GA56428@ussenterprise.ufp.org> References: <20120806142124.GA56428@ussenterprise.ufp.org> Message-ID: On Mon, Aug 6, 2012 at 10:21 AM, Leo Bicknell wrote: > Which leads to an interesting question. If on top of your $100/month > "business class Internet" the provider were to charge $50/month for > "BGP Access" to cover their costs of having a human configure the > session, larger access gear to handle the routes, and larger backbone > gear to deal with a larger routing table, would you still be as > gung ho about BGP to the business? Speaking for myself, yes, I'd pay the extra $50 and be glad. If it was $500... well, I don't have that level of need for my basement. But I have two clients who would gladly add $500 on top of a business fios to get BGP. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Mon Aug 6 09:36:26 2012 From: joelja at bogus.com (joel jaeggli) Date: Mon, 06 Aug 2012 07:36:26 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: <501FD66A.6090004@bogus.com> On 8/6/12 7:08 AM, Christopher Morrow wrote: > On Mon, Aug 6, 2012 at 9:07 AM, William Herrin wrote: >> As much as I'd love for >> Verizon to offer BGP directly over FIOS there are fewer than 40,000 > I'm curious as to your number... where is that from? sent to your mailbox every week AS Summary 41838 Number of ASes in routing system http://www.cidr-report.org/as2.0/#General_Status the majority of those are stub ASes and more than 1/3 of them are announcing only one prefix. The addressable market of potential multihomers is probably larger than that. but frankly there's a lot of friction that makes the proposition less than worthwhile for most businesses. e.g. p.i. versus pa prefix assignment. longish commitments to two or more providers facilties expertise ... In ipv4 land, a nat box with two uplinks is probably a 90% solution for most non-services-offering high(er) availability needing small businesses. > Marhsall had noted a number of 'small businesses' in the US at ~1.4m > as of ~2006ish? > > I'd think that there are many use-cases where BGP is useful for end > users of FIOS, turning out a 'business' class of service without BGP > seems like a less useful 'business' solution (especially where the sla > isn't really much better than the consumer solution). > > -chris > From morrowc.lists at gmail.com Mon Aug 6 09:45:03 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 6 Aug 2012 10:45:03 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: On Mon, Aug 6, 2012 at 10:27 AM, William Herrin wrote: > On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow > wrote: >> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin wrote: >>> As much as I'd love for >>> Verizon to offer BGP directly over FIOS there are fewer than 40,000 >> >> I'm curious as to your number... where is that from? >> Marhsall had noted a number of 'small businesses' in the US at ~1.4m >> as of ~2006ish? > > Hi Chris, > > Lacking any reason to believe otherwise, I estimate the number of BGP > users at reasonably close to the number of autonomous systems in the > Internet BGP table. Technically that doesn't have to be true... but > given the debugging nuissance associated with private AS numbers and > the trivial ease and cost with which an AS is registered it seems > likely to me. I know that 701 had many 'private' (AS7046) customer peerings than public... it doesn't seem out of the realm of possibility that other networks have the same situation. I think Marshall's numbers were based on some small-business-SEC thing, it'd be nice if he piped up with where he got the number though :( From morrowc.lists at gmail.com Mon Aug 6 09:59:41 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 6 Aug 2012 10:59:41 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: On Mon, Aug 6, 2012 at 10:45 AM, Christopher Morrow wrote: > On Mon, Aug 6, 2012 at 10:27 AM, William Herrin wrote: >> On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow >> wrote: >>> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin wrote: >>>> As much as I'd love for >>>> Verizon to offer BGP directly over FIOS there are fewer than 40,000 >>> >>> I'm curious as to your number... where is that from? >>> Marhsall had noted a number of 'small businesses' in the US at ~1.4m >>> as of ~2006ish? >> >> Hi Chris, >> >> Lacking any reason to believe otherwise, I estimate the number of BGP >> users at reasonably close to the number of autonomous systems in the >> Internet BGP table. Technically that doesn't have to be true... but >> given the debugging nuissance associated with private AS numbers and >> the trivial ease and cost with which an AS is registered it seems >> likely to me. > > I know that 701 had many 'private' (AS7046) customer peerings than > public... it doesn't seem out of the realm of possibility that other > networks have the same situation. I think Marshall's numbers were > based on some small-business-SEC thing, it'd be nice if he piped up > with where he got the number though :( I did some searching with webcrawler and found: which on slide 2 credits marshall (from before the slide which is dated 2005), the actual number is not (sadly) shown in the slides... This message from Marshall alludes to sending the numbers to Vince Fuller, Marshall goes on to say: "Yes, I gave numbers to Vince Fuller about millions of multi-homers, but that was to set an upper bound on the process. I do no believe that every small business will rush out and multi-home, no matter how automated BGP becomes." So clearly he's betting as Joel has (and William as well) that the number will be below his 1.4m total businesses, but above the current 40k asns, I would think. -chris From cboyd at gizmopartners.com Mon Aug 6 10:05:30 2012 From: cboyd at gizmopartners.com (Chris Boyd) Date: Mon, 6 Aug 2012 10:05:30 -0500 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: <030DCAD8-FF09-4B60-B198-8D37379A39EB@gizmopartners.com> On Aug 6, 2012, at 9:08 AM, Christopher Morrow wrote: > I'm curious as to your number... where is that from? > Marhsall had noted a number of 'small businesses' in the US at ~1.4m > as of ~2006ish? Speaking as someone who does a lot of work supporting small business IT, I suspect the number is much lower. As a group, these customers tend to be extremely cost averse. Paying for a secondary access circuit may become important as cloud applications become more critical for the market segment, but existing smart NAT boxes that detect primary upstream failure and switch over to a secondary ISP will work for many cases. Yes, it's ugly, but it gets them reconnected to the off-site email server and the payment card gateway. --Chris From bicknell at ufp.org Mon Aug 6 10:11:12 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 6 Aug 2012 08:11:12 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <030DCAD8-FF09-4B60-B198-8D37379A39EB@gizmopartners.com> References: <030DCAD8-FF09-4B60-B198-8D37379A39EB@gizmopartners.com> Message-ID: <20120806151112.GA59201@ussenterprise.ufp.org> In a message written on Mon, Aug 06, 2012 at 10:05:30AM -0500, Chris Boyd wrote: > Speaking as someone who does a lot of work supporting small business IT, I suspect the number is much lower. As a group, these customers tend to be extremely cost averse. Paying for a secondary access circuit may become important as cloud applications become more critical for the market segment, but existing smart NAT boxes that detect primary upstream failure and switch over to a secondary ISP will work for many cases. Yes, it's ugly, but it gets them reconnected to the off-site email server and the payment card gateway. I don't even think the dual-uplink NAT box is that ugly of a solution. Sure it's outbound only, but for a lot of applications that's fine. However, it causes me to ask a differnet question, how will this work in IPv6? Does anyone make a dual-uplink IPv6 aware device? Ideally it would use DHCP-PD to get prefixes from two upstream providers and would make both available on the local LAN. Conceptually it would then be easy to policy route traffic to the correct provider. But of course the problem comes down to the host, it now needs to know how to switch between source addresses in some meaningful way, and the router needs to be able to signal it. As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might be a relatively clean solution. Are there other deployable, or nearly deployable solutions? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From swmike at swm.pp.se Mon Aug 6 10:19:56 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 6 Aug 2012 17:19:56 +0200 (CEST) Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <20120806151112.GA59201@ussenterprise.ufp.org> References: <030DCAD8-FF09-4B60-B198-8D37379A39EB@gizmopartners.com> <20120806151112.GA59201@ussenterprise.ufp.org> Message-ID: On Mon, 6 Aug 2012, Leo Bicknell wrote: > However, it causes me to ask a differnet question, how will this work in > IPv6? Does anyone make a dual-uplink IPv6 aware device? Ideally it > would use DHCP-PD to get prefixes from two upstream providers and would > make both available on the local LAN. Conceptually it would then be > easy to policy route traffic to the correct provider. But of course the > problem comes down to the host, it now needs to know how to switch > between source addresses in some meaningful way, and the router needs to > be able to signal it. There are working groups in the IETF looking into how to make this work, "homenet", "v6ops" and a few others. After a while one runs into protocol extensions or behavioural changes and things become non-trivial. > As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might be a > relatively clean solution. Are there other deployable, or nearly > deployable solutions? Yes, there are a lot of possible options. Feel free to participate in the process. There is nothing that is deployable right now though. -- Mikael Abrahamsson email: swmike at swm.pp.se From davidpeahi at gmail.com Mon Aug 6 11:47:30 2012 From: davidpeahi at gmail.com (david peahi) Date: Mon, 6 Aug 2012 09:47:30 -0700 Subject: Cisco 7200 PCI Limitations In-Reply-To: <501B7F86.1090709@shthead.com> References: <501B7F86.1090709@shthead.com> Message-ID: The 7200 architecture dates from the late 1990s, and is basically modeled on a PCI-bus UNIX workstation from that era. The 7200 is usable today as a WAN aggregation router for T1 access, and nothing else. Using it as a GiGE transit router will place a non-deterministic node in the network, unable to scale to the 4 GiGE full-duplex throughput. Even worse is creating a portchannel out of the 7200 GiGE interfaces and using dot1q sub-interfaces to emulate an Ethernet switch in 7200 software, then connecting the 7200 dot1q trunk to a modern Ethernet switch with a wire speed backplane (for example a Cisco 3560X Ethernet switch). Long since considered an unacceptable best practice (due to the 7200 backplane limitation vs adjacent, directly connected modern Ethernet switches), Cisco is still teaching portchannel in its router configuration classes, so relatively new network engineers have actually been known to use this ill-considered configuration. If a 4 port GiGE Cisco router is needed, then the ASR1001 is the modern version of the 7206, with wire speed throughput. On Fri, Aug 3, 2012 at 12:36 AM, shthead wrote: > Hi all, > > I have a 7200 series router (7204) here and I am trying to figure out > something with it. Currently the router has a NPE-G1 card in it, giving it > 3 gig interfaces but I need an extra gig interface on it to make 4. > > Having a look around the available options are either get a PA-GE card > that fits into one of the slots on the router or to get a C7200-I/O-GE+E > (I/O controller with a gbit port on it). > > The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus > will limit it to 300mbit full duplex (and it goes on further to say it will > be limited to approx 200mbit in best case scenario due to the design of the > card) [1]. > > The other option left is the I/O controller. I found that you can get a > port adaptor jacket card [2] for the 7200's that let you stick a normal > interface card into the I/O controller slot (instead of the I/O controller > itself). > > My main concern is if the jacket card uses its own PCI bus I am assuming > the C7200-I/O-GE+E also connects via PCI which means it would be subject to > the same limitations as the PA-GE. > > Does anyone have any idea if that would be correct and the only option for > another gbit port would be to get another device? > > Thanks for the help > > [1] http://www.cisco.com/en/US/**products/hw/routers/ps341/** > products_tech_**note09186a00800c814a.shtml#**backinfo > [2] http://www.cisco.com/en/US/**prod/collateral/routers/ps341/** > prod_qas0900aecd8045055e.html > > From mike at mikejones.in Mon Aug 6 11:51:02 2012 From: mike at mikejones.in (Mike Jones) Date: Mon, 6 Aug 2012 17:51:02 +0100 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <20120806151112.GA59201@ussenterprise.ufp.org> References: <030DCAD8-FF09-4B60-B198-8D37379A39EB@gizmopartners.com> <20120806151112.GA59201@ussenterprise.ufp.org> Message-ID: On 6 August 2012 16:11, Leo Bicknell wrote: > In a message written on Mon, Aug 06, 2012 at 10:05:30AM -0500, Chris Boyd wrote: >> Speaking as someone who does a lot of work supporting small business IT, I suspect the number is much lower. As a group, these customers tend to be extremely cost averse. Paying for a secondary access circuit may become important as cloud applications become more critical for the market segment, but existing smart NAT boxes that detect primary upstream failure and switch over to a secondary ISP will work for many cases. Yes, it's ugly, but it gets them reconnected to the off-site email server and the payment card gateway. > > I don't even think the dual-uplink NAT box is that ugly of a solution. > Sure it's outbound only, but for a lot of applications that's fine. > > However, it causes me to ask a differnet question, how will this > work in IPv6? Does anyone make a dual-uplink IPv6 aware device? > Ideally it would use DHCP-PD to get prefixes from two upstream > providers and would make both available on the local LAN. Conceptually > it would then be easy to policy route traffic to the correct provider. > But of course the problem comes down to the host, it now needs to > know how to switch between source addresses in some meaningful way, > and the router needs to be able to signal it. Multiple prefixes is very simple to do without needing a dual uplink router, just get 2 "normal" routers and have them both advertise their own prefixes, the problem is the policy routing that you mentioned a dual WAN router would do. A client that sees prefix A from router A and prefix B from router B should IMO prefer router A for traffic from prefix A and router B for traffic from prefix B. Current implementations seem to abstract away the addressing and the routing in to completely separate things resulting in it picking a default router then using that for all traffic, this isn't too much of a problem if neither of your upstreams do any source address filtering but I would much rather OS vendors change their implementations than tell ISPs to stop filtering their customers. > As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might > be a relatively clean solution. Are there other deployable, or nearly > deployable solutions? If you have a router that sends out RAs with lifetime 0 when the prefix goes away then this should be deployable for "poor mans failover" (the same category I put IPv4 NAT in), however there are some bugs with client implementations and some clients might refuse to use that prefix/router again until they have rebooted which could be an issue for infrequently rebooted clients if the other connection later goes down. A lifetime of 1 instead of 0 should in theory work around this behaviour but I haven't seen any implementations that do this and haven't tested myself. It's a shame that this IPv6 stuff doesn't work properly out of the box, I fear that there will be a lot of hackery due to early limitations that will stick around - for example if NAT becomes readily available before clients can properly handle multiple prefixes from multiple routers (and DHCP-PD chaining, and the various other "we're working on it" things), then even once clients start being able to do it properly I suspect people will still stick to their beloved NAT because that's what they are used to. - Mike From paul4004 at gmail.com Mon Aug 6 12:04:58 2012 From: paul4004 at gmail.com (PC) Date: Mon, 6 Aug 2012 11:04:58 -0600 Subject: Cisco 7200 PCI Limitations In-Reply-To: References: <501B7F86.1090709@shthead.com> Message-ID: While I agree it may not be suitable for transit GigE purposes, it is certainly acceptable for many WAN aggregation scenarios and CPE scenarios well in excess of T1 speeds. There are still many out there in DS3, Fast-E, subrate ethernet subscriber, ATM, (DSL/L2TP/PPPOE), DMVPN, and other similar scenarios. For this, while often not ideal, they continue to work fine. On Mon, Aug 6, 2012 at 10:47 AM, david peahi wrote: > The 7200 architecture dates from the late 1990s, and is basically modeled > on a PCI-bus UNIX workstation from that era. The 7200 is usable today as a > WAN aggregation router for T1 access, and nothing else. Using it as a GiGE > transit router will place a non-deterministic node in the network, unable > to scale to the 4 GiGE full-duplex throughput. Even worse is creating a > portchannel out of the 7200 GiGE interfaces and using dot1q sub-interfaces > to emulate an Ethernet switch in 7200 software, then connecting the 7200 > dot1q trunk to a modern Ethernet switch with a wire speed backplane (for > example a Cisco 3560X Ethernet switch). > Long since considered an unacceptable best practice (due to the 7200 > backplane limitation vs adjacent, directly connected modern Ethernet > switches), Cisco is still teaching portchannel in its router configuration > classes, so relatively new network engineers have actually been known to > use this ill-considered configuration. > If a 4 port GiGE Cisco router is needed, then the ASR1001 is the modern > version of the 7206, with wire speed throughput. > > On Fri, Aug 3, 2012 at 12:36 AM, shthead wrote: > > > Hi all, > > > > I have a 7200 series router (7204) here and I am trying to figure out > > something with it. Currently the router has a NPE-G1 card in it, giving > it > > 3 gig interfaces but I need an extra gig interface on it to make 4. > > > > Having a look around the available options are either get a PA-GE card > > that fits into one of the slots on the router or to get a C7200-I/O-GE+E > > (I/O controller with a gbit port on it). > > > > The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus > > will limit it to 300mbit full duplex (and it goes on further to say it > will > > be limited to approx 200mbit in best case scenario due to the design of > the > > card) [1]. > > > > The other option left is the I/O controller. I found that you can get a > > port adaptor jacket card [2] for the 7200's that let you stick a normal > > interface card into the I/O controller slot (instead of the I/O > controller > > itself). > > > > My main concern is if the jacket card uses its own PCI bus I am assuming > > the C7200-I/O-GE+E also connects via PCI which means it would be subject > to > > the same limitations as the PA-GE. > > > > Does anyone have any idea if that would be correct and the only option > for > > another gbit port would be to get another device? > > > > Thanks for the help > > > > [1] http://www.cisco.com/en/US/**products/hw/routers/ps341/** > > products_tech_**note09186a00800c814a.shtml#**backinfo< > http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note09186a00800c814a.shtml#backinfo > > > > [2] http://www.cisco.com/en/US/**prod/collateral/routers/ps341/** > > prod_qas0900aecd8045055e.html< > http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_qas0900aecd8045055e.html > > > > > > > From bicknell at ufp.org Mon Aug 6 12:26:41 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 6 Aug 2012 10:26:41 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: <030DCAD8-FF09-4B60-B198-8D37379A39EB@gizmopartners.com> <20120806151112.GA59201@ussenterprise.ufp.org> Message-ID: <20120806172641.GA64279@ussenterprise.ufp.org> In a message written on Mon, Aug 06, 2012 at 05:51:02PM +0100, Mike Jones wrote: > If you have a router that sends out RAs with lifetime 0 when the > prefix goes away then this should be deployable for "poor mans > failover" (the same category I put IPv4 NAT in), however there are If your provider does Unicast RPF strict mode, which I hope _all_ end user and small business connections default to doing this won't work. The traffic has to be policy routed out based on the source IP. Having the host stack do that is an acceptable solution (your dual router model) I think, but I don't know of a single one that does that today. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From frnkblk at iname.com Mon Aug 6 13:31:18 2012 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 6 Aug 2012 13:31:18 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <116ED2ECE3E1764BB9777152785AB9E80CE855FC@EXCH2010.torrance.interworld.net> References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <20120804160904.GC22887@hiwaay.net> <00b201cd737c$f3431090$d9c931b0$@iname.com> <116ED2ECE3E1764BB9777152785AB9E80CE855FC@EXCH2010.torrance.interworld.net> Message-ID: <000601cd7401$abdd5190$0397f4b0$@iname.com> Even though we know it's technically possible, service providers aren't going to overprovision power backup unless there is a business reason to do so. Some state PUCs have minimum battery run times -- I'm sure service providers who provide telephone service are meeting that because their certificate depends on that. After that, it's just providing enough services to remain comparatively competitive. Frank -----Original Message----- From: Ralph E. Whitmore, III [mailto:ralphw at interworld.net] Sent: Sunday, August 05, 2012 11:54 PM To: nanog at nanog.org Subject: RE: Verizon FiOS - is BGP an option? What I think most people are objecting to is that most of the issue with maintain service is not related to technical capabilities, but related to the cost of providing these support services impacting the profit margins of the large monopolistic carriers. Verizon with their FIOS offerings, at least in my area is CO based and all optical, so all I have to provide is power to my own FIOS terminal which is easy to do, floated on batteries (not the POS that VZ provided but a real battery bank) and I stay online. We have been through 10 outages at least 10 hours in duration and one 3 day outage all courtesy of SCE who can't figure out how to replace the 57 year old wires that keep breaking from corrosion here in So. Calif. As a subscriber, I paid for the copper Wire that VZ installed, I paid for the Copper that Edison installed, I pay to maintain both of these services on a 7x24x365 basis. And each and every month, SCE and VZ take a mandatory deduction out of my bill specifically to replace the copper every 50 years (the design life of the infrastructure). Edison squanders that money and just patches the infrastructure with no regard for the customers, and VZ replaces the copper with FIOS so they don't have to allow any competition from anyone else and demos the copper when they are done so no one else can use it. All of these companies fail to understand that they were granted a license and handed the keys to provide a public service and we expect them to perform that job rain or shine 7x24x365. Hurricanes (while not a problem where I am) are a known problem in many parts of the company and it is their job to maintain service despite the hurricanes. These fiber huts/RSU's were installed to minimize VZ's (insert your favorite carrier here) cost of maintenance for their network . This way, they can increase their profits by laying off more workers and hiring more subcontractors. So be it, that is their business model. What people/PUC/ Regulatory bodies fail to follow up on is that just because they are allowed to install Fiber Huts/RSU's the customers should expect the same level of service and redundancy that is provided by a brick and mortar CO built to the ATT/Bellcore standards for stability and reliability. I am all for the carriers pushing the edge closer to the customers, but it should not be allowed to occur at a substandard level. They certainly aren't offering a discount for substandard service received by some. My customers get 99.999% reliability from my infrastructure, I expect the carriers to do at least as well, obviously that doesn't happen. All my Roadside cabinets have a DC plant that is engineered to hold the facility for at least 18 hours based on the equipment in the box. All my facilities have an external Transfer switch and a generator plug. A single 5kw generator, with one cable and padlock, with one tank of fuel (generally propane or diesel)(about 5 gallons) will run the hut for 8-10 hours, fully recharge the DC plant inside buying you another 18 hours on battery (therefore 28 additional hours before fuel is needed) and to boot have electronic monitoring to tell me if there is another AC failure of the generator during that 8-10 hours. One contractor, god forbid we wouldn't do this with actual employees of the company, with a pickup truck and a small trailer should be able to support between 12-20 Fiber Huts /RSU's in a single shift. If your site is bigger than a 5KW site then you should have generator backup onsite in the first place. If I can do this Verizon/ATT/Centurylink should have no trouble supporting their facilities in a similar fashion. I am a little dinky company with 12 employees, but Verizon( your carrier name here) If you want to use Wisper Watt 25KW generators, more power to you, they will just pass the costs on to us anyways in the next rate hike. The argument about lack of fuel availability is total bunk as well as I can't believe that any carrier doesn't already have 1000's of gallons onsite already to support their CO's, trucks, ect. if you need more you can order a 5000gallon tank like everyone else in the real world does, you can probably have it delivered tomorrow afternoon if you place the order tomorrow morning before noon. Lack of power at an Fiber hut/RSU is negligence at best on a carriers part, not an unsolvable technical problem My uncle who retired from Bell Atlantic/VZ after 30 years was in a rural area of Virginia and now works as a contractor for emergency restoration after storms. He was called in to work on Storm restoration he along with 20 other crews, were told report to the staging yard and wait for an assignment. It took three days to get to the staging area, They waited 4 days in the yard before being assigned work and was then told that they couldn't work more than 12 hours in a day, because VZ would only pay for a max of 4 hours OT for any personnel in a 24 hour period. They worked for 4 days and were then sent home as they were no longer needed. To the best of my recollection people were without service for weeks if not months. The safety wackos in the world will say well we don't want to tax our employees and more than 12 hours isn't safe. Ok, I will not argue the validity of their argument, personally I disagree with it, but this is an emergency response not a shareholders meeting, but sending the crews home weeks before all service is restored doesn't resonate well. IMHO Restoration was not about serving the people who were out of service, but rather spending at little as they could get away with without regard for the people who pay for the infrastructure and pay their bills. While we are at it, my uncle installed the RSU he is serviced from at his house before he retired from Bell Atlantic/VZ, they engineered only 4 hours of battery backup for their site near his house, the fiber hut/RSU is approx. 8'x8'x5' and it has only 4 -105AH batteries installed in it, there are three vacant shelves for more batteries and one totally vacant compartment left in the cabinet for battery expansion. Given the rural nature of his service RSU, the nearest stocking yard for VZ is better than an hour's drive from his RSU. Given the Union contract gives the workers 2 hours to show up at the yard from the time they are contacted ( which could take hours to do in the first place if his RSU is down) there is almost no way that you can callout a tech and make it to the site before the battery back is exhausted and Dominion Power is highly un-likely to arrive onsite in less than 12 hours from the time of call. So this site is doomed to go down from the start. A single house, my house, your house, despite what we think are not critical infrastructure to the carriers, but the fiber huts that service them certainly is and needs to be supported better than they are now. Back to the original topic, BGP works great over FIOS if you have a business account with static IP's and a Cooperative Colo. I have IPv4 and IPv6 running at my house and office (we microwave the Home's business FIOS to the office) through a GRE tunnel. It's the cheapest 35x35Mb connection around for about $200.00 with 32 static IP's around TWC wants about $2k for the same service. It took a little bit of fiddling to get the MTU right across the tunnel (ip tcp adjust-mss is your friend) I could upgrade the service for another $100.00 to 150Mb x 65Mb, but the wireless link won't support that without a large expenditure and for 12 people it's not needed. Boy that was a lot, glad I had time on a Sunday night to write this after fueling my generator. Ralph -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, August 05, 2012 7:41 PM To: 'William Herrin'; Andy Koch Cc: nanog at nanog.org Subject: RE: Verizon FiOS - is BGP an option? I think the term "critical" is being used in different senses in this discussion. Are people's lives critical? Yes, but the regulations for wired and wireless infrastructure don't require service providers to expend any and all costs to maintain connectivity. And we don't have ambulances and fire trucks at every corner and hospitals in every subdivision. Despite the almost incalculable value of life, there are still limitations on all the services provided to residences. Would I like to have the same uptime at my home as we have in the CO? or data center? Sure, but collectively we aren't willing, nay, able, to pay that price. Frank -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Saturday, August 04, 2012 11:15 PM To: Andy Koch Cc: nanog at nanog.org Subject: Re: Verizon FiOS - is BGP an option? On Sat, Aug 4, 2012 at 10:26 PM, Nathan Eisenberg wrote: >> Residences aren't critical infrastructure, no matter how angry the >> owners get. > > 911 access isn't a critical service? Fire and security panels aren't critical services? > If basic life safety and property protection aren't critical services, > I'm not sure what is. Whether each individual's residence contains critical infrastructure is a decision best left up to that individual. By necessity that makes the upstream aggregation components critical infrastructure. No different than it was for POTS 20 years ago. The Internet isn't just a toy any more. It's the primary communications channel in to many folks homes and well on its way to becoming the primary channel period. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Aug 6 14:06:00 2012 From: bill at herrin.us (William Herrin) Date: Mon, 6 Aug 2012 09:06:00 -1000 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <000601cd7401$abdd5190$0397f4b0$@iname.com> References: <4F61508C.9040703@xyonet.com> <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> <501BEDBD.1020503@pubnix.net> <501C1DB3.7060209@rollernet.us> <00cd01cd71be$b56718d0$20354a70$@iname.com> <20120804150212.GB22887@hiwaay.net> <20120804160904.GC22887@hiwaay.net> <00b201cd737c$f3431090$d9c931b0$@iname.com> <116ED2ECE3E1764BB9777152785AB9E80CE855FC@EXCH2010.torrance.interworld.net> <000601cd7401$abdd5190$0397f4b0$@iname.com> Message-ID: On Mon, Aug 6, 2012 at 8:31 AM, Frank Bulk wrote: > Even though we know it's technically possible, service providers aren't > going to overprovision power backup unless there is a business reason to do > so. Some state PUCs have minimum battery run times -- I'm sure service > providers who provide telephone service are meeting that because their > certificate depends on that. After that, it's just providing enough > services to remain comparatively competitive. It's unfortunate that some of them intend to wait for the PUCs and SCCs to compel them to maintain service availability at the level they learned to do it at for POTS. And then complain nodoubt about how much it costs since they didn't architect their network to be friendly to power backup. Don't these guys ever want to get ahead of the curve? If they want to keep making the case for being allowed to operate an unregulated monopoly/duopoly "information service," it seems like it would be unwise to provoke State Corporation Commission with service outages. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon Aug 6 15:02:04 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Aug 2012 13:02:04 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <20120806142124.GA56428@ussenterprise.ufp.org> References: <20120806142124.GA56428@ussenterprise.ufp.org> Message-ID: <355FE7FE-3636-457D-B3D3-898B75FFD2C5@delong.com> On Aug 6, 2012, at 07:21 , Leo Bicknell wrote: > In a message written on Mon, Aug 06, 2012 at 01:49:07AM -0500, jamie rishaw wrote: >> discuss. > > It's a short sighted result created by the lack of competition. > > IP access is a commodity service, with thin margins that will only > get thinner. Right now those margins are being propped up in many > locations by monopoly or near-monopoly status, which creates a > situation where companies neither need to compete on features and > service quality nor do they need to turn to those areas to maintain > a profit. > > If there was meaningful competition, the margin on raw IP access > would decline and companies would have to turn to value-add services > to maintain a profit margin. From the simple up-sell of a static > IP address that some do today, to a fee for BGP, a fee for DDOS > mitigation, and so on. These are all things it's not uncommon to > see when buying service in carrier netural colos where there is > competition. > > There is no technological problem here. BGP to the end user has a > cost. The current business climate is causing people to cut all > possible costs and offering no incentive to innvovate and up-charge. > > Which leads to an interesting question. If on top of your $100/month > "business class Internet" the provider were to charge $50/month for > "BGP Access" to cover their costs of having a human configure the > session, larger access gear to handle the routes, and larger backbone > gear to deal with a larger routing table, would you still be as > gung ho about BGP to the business? > I'd pay it in a heartbeat. Owen From owen at delong.com Mon Aug 6 15:03:10 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Aug 2012 13:03:10 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: Message-ID: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> On Aug 6, 2012, at 07:27 , William Herrin wrote: > On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow > wrote: >> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin wrote: >>> As much as I'd love for >>> Verizon to offer BGP directly over FIOS there are fewer than 40,000 >> >> I'm curious as to your number... where is that from? >> Marhsall had noted a number of 'small businesses' in the US at ~1.4m >> as of ~2006ish? > > Hi Chris, > > Lacking any reason to believe otherwise, I estimate the number of BGP > users at reasonably close to the number of autonomous systems in the > Internet BGP table. Technically that doesn't have to be true... but > given the debugging nuissance associated with private AS numbers and > the trivial ease and cost with which an AS is registered it seems > likely to me. > This ignores the probability that cost effective BGP service availability would strongly drive demand for AS Numbers and adoption of the technology. Owen From khelms at ispalliance.net Mon Aug 6 15:16:34 2012 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 06 Aug 2012 16:16:34 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> Message-ID: <50202622.8010706@ispalliance.net> Probability is much too strong IMO. Most businesses don't even consider multi-homing and many that do use NAT devices with several connections rather than trying to run BGP. #not associated nor do I recommend, just an example http://www.fatpipeinc.com/warp/index.html > This ignores the probability that cost effective BGP service availability would > strongly drive demand for AS Numbers and adoption of the technology. > > Owen > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From owen at delong.com Mon Aug 6 15:27:54 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Aug 2012 13:27:54 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <50202622.8010706@ispalliance.net> References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> Message-ID: Respectfully, I disagree... I think this is a causal chain... 1. Lack of cost-effective BGP-based service means that 2. CPE vendors are not motivated to provide self-configuring bgp-speaking routers to behave in this manner means that 3. SMBs seek other solutions using available CPE technology. If cost-effective BGP-based service were available, providers would likely work with CPE vendors to get automation features added to products to support such services and multihomed organizations would definitely want to use those features. Owen On Aug 6, 2012, at 13:16 , Scott Helms wrote: > Probability is much too strong IMO. Most businesses don't even consider multi-homing and many that do use NAT devices with several connections rather than trying to run BGP. > > #not associated nor do I recommend, just an example > > http://www.fatpipeinc.com/warp/index.html > > >> This ignores the probability that cost effective BGP service availability would >> strongly drive demand for AS Numbers and adoption of the technology. >> >> Owen >> >> >> > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > From jim at neuse.net Mon Aug 6 16:27:20 2012 From: jim at neuse.net (Jim Ray) Date: Mon, 6 Aug 2012 17:27:20 -0400 Subject: next hop packet loss Message-ID: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> Good afternoon. I am a newbie to this group, and this post is my first post ever. A friend from another list recommended this group. I have a Time Warner Business Class connection and am unable to reach http://www.checkpoint.com to research product line I wish to carry. I did a trace route and confirmed packets are past my network, Time Warner network and onto next hop where they execute jump to nowhere instruction. Time Warner says it is off their network, and they can't help. I received no reply from above.net next hop. What is the best way to solve this type of problem? Here is the tracert just now (it has been failing for weeks): C:\Documents and Settings\jim.ray>tracert checkpoint.com Tracing route to checkpoint.com [216.200.241.66] over a maximum of 30 hops: 1 52 ms 28 ms 37 ms 10.129.96.1 2 10 ms 12 ms 16 ms ten13-0-0-238.rlghnca-rtr1.nc.rr.com [66.26.32.2 42] 3 16 ms 12 ms 12 ms ae19.rlghncpop-rtr1.southeast.rr.com [24.93.64.0 ] 4 19 ms 23 ms 24 ms 107.14.19.20 5 16 ms 19 ms 19 ms 107.14.19.133 6 28 ms 20 ms 19 ms xe-0-1-1.er2.iad10.us.above.net [64.125.12.61] 7 23 ms 19 ms 19 ms xe-2-0-0.cr2.dca2.us.above.net [64.125.31.209] 8 74 ms 49 ms 56 ms xe-0-2-0.cr2.iah1.us.above.net [64.125.28.50] 9 77 ms 79 ms 79 ms xe-0-3-0.cr2.lax112.us.above.net [64.125.30.50] 10 85 ms 86 ms 86 ms xe-1-0-0.cr2.sjc2.us.above.net [64.125.31.233] 11 84 ms 92 ms 86 ms xe-1-1-0.er2.sjc2.us.above.net [64.125.26.202] 12 86 ms 86 ms 105 ms 64.124.201.230.b709.above.net [64.124.201.230] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 16530 bytes Desc: image001.jpg URL: From micah at riseup.net Thu Aug 2 12:59:51 2012 From: micah at riseup.net (Micah Anderson) Date: Thu, 02 Aug 2012 13:59:51 -0400 Subject: Wanted: Asia bandwidth test files Message-ID: <87zk6d899k.fsf@minnow.riseup.net> Hi, I'm sitting on what is advertised as a 100mbit/sec connection in Cambodia. I have been trying to verify that, because I do not believe it is valid. I did iperf tests from a number of network locations, and at one point I did get 71mbit/sec (most of the results were around 20-25mbit/sec or less). But I dont think 30 second iperf tests are particularly revealing when the bandwith rate might change drastically over the day. I considered doing a 3 day iperf test, but somehow this seems not how the tool was designed. Someone suggested I find test files from various Asian locations to download via wget. I found a bunch of 100mb test files for various providers in N. America and Europe on webhostingtalk, which were interesting, but I never got more than around 5mbit/sec with them. Does anyone have any machines in Japan, S. Korea, or other asian locations with good bandwidth. where they can host a 100mbit file so I can attempt to download it to test this? Other suggestions for reliable tests would also be welcome! Please, dont suggest some flash garbage :) thanks! micah -- From tom.taylor.stds at gmail.com Mon Aug 6 09:25:09 2012 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Mon, 06 Aug 2012 10:25:09 -0400 Subject: IETF contacts? - Fwd: Reference to historic or obsolated RFCs In-Reply-To: References: Message-ID: <501FD3C5.4080908@gmail.com> I'd suggest the ietf-discussion list, since it's a matter for general discussion. On 06/08/2012 10:10 AM, Livio Zanol Puppim wrote: > Hello guys, > > I've sent the e-mail below to IETF, but I couldn't find a contact e-mail to > address this kind of subject in IETF site. Does anybody knows which e-mail > to send this? > > The contact page from IETF website: > http://www.ietf.org/contact-the-ietf.html > > ---------- Forwarded message ---------- > From: Livio Zanol Puppim > Date: 2012/8/6 > Subject: Reference to historic or obsolated RFCs > To: ietf-info at ietf.org, ietf-action at ietf.org > > > Hello, > > I don't know which contact to send this e-mail, so I'm copying the INFO and > ACTION e-mail... If these are the wrong contact, can you please point me > the correct e-mail? > > Reading the *RFC 5375* I've found references to some RFCs that are > considered Historic, or have been updated. In some cases, this can lead to > a misunderstand of a a section in a RFC. > > For example: > The* RFC 5375* in section *B.2.2* states that we should avoid using /127 > IPv6 prefix, but* RFC 6164* clearly says that we can use /127 prefix for > Inter-Router links. In fact, the *RFC 6547*, moves the *RFC > 3627*(referenced by the > * RFC 5375* in the above section) to Historic status. > > If my point of view is indeed correct, I think that everytime a new RFC is > published that proposes an *Update* to another RFC, or *Obsoletes* another > RFC or moves a RFC to *Historic *status, the team responsible for it's > creation needs to read every reference to that RFC and request changes in > order to avoid this kind of misunderstanding. This is very important to > guys like me, that only reads the RFCs. > > the section from RFC 5375 > http://tools.ietf.org/html/rfc5375#appendix-B.2.2 > > " > > > B.2.2 . /127 Addresses > > The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 > > [RFC3021 ], is not valid and > should be strongly discouraged as > documented in RFC 3627 > [RFC3627 ]. > > " > From sadiq at asininetech.com Mon Aug 6 16:46:51 2012 From: sadiq at asininetech.com (Sadiq Saif) Date: Mon, 6 Aug 2012 17:46:51 -0400 Subject: Wanted: Asia bandwidth test files In-Reply-To: <87zk6d899k.fsf@minnow.riseup.net> References: <87zk6d899k.fsf@minnow.riseup.net> Message-ID: Linode hosts one to test their Tokyo location - http://speedtest.tokyo.linode.com/100MB-tokyo.bin Source - http://www.linode.com/speedtest/ On Thu, Aug 2, 2012 at 1:59 PM, Micah Anderson wrote: > > Hi, > > I'm sitting on what is advertised as a 100mbit/sec connection in > Cambodia. I have been trying to verify that, because I do not believe it > is valid. > > I did iperf tests from a number of network locations, and at one point I > did get 71mbit/sec (most of the results were around 20-25mbit/sec or > less). But I dont think 30 second iperf tests are particularly revealing > when the bandwith rate might change drastically over the day. I > considered doing a 3 day iperf test, but somehow this seems not how the > tool was designed. > > Someone suggested I find test files from various Asian locations to > download via wget. I found a bunch of 100mb test files for various > providers in N. America and Europe on webhostingtalk, which were > interesting, but I never got more than around 5mbit/sec with them. > > Does anyone have any machines in Japan, S. Korea, or other asian > locations with good bandwidth. where they can host a 100mbit file so I > can attempt to download it to test this? > > Other suggestions for reliable tests would also be welcome! Please, dont > suggest some flash garbage :) > > thanks! > micah > > -- > > -- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From tom at ninjabadger.net Mon Aug 6 16:50:43 2012 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 06 Aug 2012 22:50:43 +0100 Subject: next hop packet loss In-Reply-To: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> References: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> Message-ID: <50203C33.9040506@ninjabadger.net> Hi Jim, On 06/08/12 22:27, Jim Ray wrote: > What is the best way to solve this type of problem? It's not a problem, it's checkpoint purporting to be 'secure' when all they're doing is blocking ICMP outright, seemingly. If I try 'tcptraceroute' (from Linux) it works just fine, bare the Above.net hop in the middle that doesn't respond - ignore. $ sudo tcptraceroute -n checkpoint.com traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte packets 1 81.187.203.81 0.719 ms 1.050 ms 1.298 ms 2 90.155.53.54 30.184 ms 31.604 ms 32.370 ms 3 90.155.53.43 33.891 ms 35.072 ms 36.021 ms 4 85.91.238.217 37.016 ms 38.236 ms 39.215 ms 5 85.91.224.10 40.226 ms 41.358 ms 42.354 ms 6 212.187.200.145 164.713 ms 164.102 ms 164.020 ms 7 4.69.139.99 45.316 ms 194.042 ms 194.088 ms 8 64.125.14.17 194.297 ms 193.943 ms 193.558 ms 9 64.125.31.198 194.304 ms 194.462 ms 193.560 ms 10 * * * 11 64.125.26.37 288.267 ms 284.237 ms 166.340 ms 12 64.125.24.38 178.571 ms 179.467 ms 156.769 ms 13 64.125.28.238 148.002 ms 147.244 ms 147.501 ms 14 64.125.26.141 206.010 ms 205.574 ms 205.426 ms 15 64.125.28.57 201.753 ms 172.439 ms 174.169 ms 16 64.124.201.230 176.866 ms 172.412 ms 172.510 ms 17 208.185.174.208 173.668 ms 174.310 ms 173.999 ms 18 216.200.241.66 172.504 ms 172.386 ms 172.700 ms Tom From khelms at ispalliance.net Mon Aug 6 17:05:21 2012 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 06 Aug 2012 18:05:21 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> Message-ID: <50203FA1.8050503@ispalliance.net> Owen, That's like saying if it were easy to fly we'd all be pilots, which isn't true either. BGP would need to be completely redesigned/replaced before it could possibly be automated to that level much less implemented by the Lynksis/DLink/Netgear/$yourfavoritesohorouter vendor. Business would need a reason to implement BGP and most simply don't AND BGP would have to be dramatically simpler and safer. Operators already have to be deeply involved (AKA filtering the announced networks) with edge network BGP implementations to prevent someone from announcing they're the preferred route for some other organization's netblock. This happens already on occasion and all of the people who run routers speaking BGP are generally professionals. On 8/6/2012 4:27 PM, Owen DeLong wrote: > Respectfully, I disagree... I think this is a causal chain... > > 1. Lack of cost-effective BGP-based service means that > 2. CPE vendors are not motivated to provide self-configuring bgp-speaking routers to behave in this manner means that > 3. SMBs seek other solutions using available CPE technology. > > If cost-effective BGP-based service were available, providers would likely work with CPE vendors to get automation features added to products to support such services and multihomed organizations would definitely want to use those features. > > Owen > > On Aug 6, 2012, at 13:16 , Scott Helms wrote: > >> Probability is much too strong IMO. Most businesses don't even consider multi-homing and many that do use NAT devices with several connections rather than trying to run BGP. >> >> #not associated nor do I recommend, just an example >> >> http://www.fatpipeinc.com/warp/index.html >> >> >>> This ignores the probability that cost effective BGP service availability would >>> strongly drive demand for AS Numbers and adoption of the technology. >>> >>> Owen >>> >>> >>> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From shtsuchi at cisco.com Mon Aug 6 17:10:02 2012 From: shtsuchi at cisco.com (Shishio Tsuchiya) Date: Tue, 07 Aug 2012 07:10:02 +0900 Subject: Wanted: Asia bandwidth test files In-Reply-To: <87zk6d899k.fsf@minnow.riseup.net> References: <87zk6d899k.fsf@minnow.riseup.net> Message-ID: <502040BA.1020403@cisco.com> Hi I think RING project NLNOG has potential to help your effort. https://ring.nlnog.net/ At least they have location in tokyo. And I talked with Seichi Kawamura who is leader of JANOG about method of quality?verification among the world wide. They are using host of Softlayer, amazon and OVH which could select the location. Job and Mucho ccing. Regards, -Shishio (2012/08/03 2:59), Micah Anderson wrote: > > Hi, > > I'm sitting on what is advertised as a 100mbit/sec connection in > Cambodia. I have been trying to verify that, because I do not believe it > is valid. > > I did iperf tests from a number of network locations, and at one point I > did get 71mbit/sec (most of the results were around 20-25mbit/sec or > less). But I dont think 30 second iperf tests are particularly revealing > when the bandwith rate might change drastically over the day. I > considered doing a 3 day iperf test, but somehow this seems not how the > tool was designed. > > Someone suggested I find test files from various Asian locations to > download via wget. I found a bunch of 100mb test files for various > providers in N. America and Europe on webhostingtalk, which were > interesting, but I never got more than around 5mbit/sec with them. > > Does anyone have any machines in Japan, S. Korea, or other asian > locations with good bandwidth. where they can host a 100mbit file so I > can attempt to download it to test this? > > Other suggestions for reliable tests would also be welcome! Please, dont > suggest some flash garbage :) > > thanks! > micah > From jim at neuse.net Mon Aug 6 17:37:58 2012 From: jim at neuse.net (Jim Ray) Date: Mon, 6 Aug 2012 18:37:58 -0400 Subject: next hop packet loss In-Reply-To: <50203C33.9040506@ninjabadger.net> References: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> <50203C33.9040506@ninjabadger.net> Message-ID: It is a problem with http protocol regardless of ICMP. Sent from my iPhone On Aug 6, 2012, at 5:51 PM, "Tom Hill" wrote: > Hi Jim, > > On 06/08/12 22:27, Jim Ray wrote: >> What is the best way to solve this type of problem? > > It's not a problem, it's checkpoint purporting to be 'secure' when all they're doing is blocking ICMP outright, seemingly. > > If I try 'tcptraceroute' (from Linux) it works just fine, bare the Above.net hop in the middle that doesn't respond - ignore. > > $ sudo tcptraceroute -n checkpoint.com > traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte packets > 1 81.187.203.81 0.719 ms 1.050 ms 1.298 ms > 2 90.155.53.54 30.184 ms 31.604 ms 32.370 ms > 3 90.155.53.43 33.891 ms 35.072 ms 36.021 ms > 4 85.91.238.217 37.016 ms 38.236 ms 39.215 ms > 5 85.91.224.10 40.226 ms 41.358 ms 42.354 ms > 6 212.187.200.145 164.713 ms 164.102 ms 164.020 ms > 7 4.69.139.99 45.316 ms 194.042 ms 194.088 ms > 8 64.125.14.17 194.297 ms 193.943 ms 193.558 ms > 9 64.125.31.198 194.304 ms 194.462 ms 193.560 ms > 10 * * * > 11 64.125.26.37 288.267 ms 284.237 ms 166.340 ms > 12 64.125.24.38 178.571 ms 179.467 ms 156.769 ms > 13 64.125.28.238 148.002 ms 147.244 ms 147.501 ms > 14 64.125.26.141 206.010 ms 205.574 ms 205.426 ms > 15 64.125.28.57 201.753 ms 172.439 ms 174.169 ms > 16 64.124.201.230 176.866 ms 172.412 ms 172.510 ms > 17 208.185.174.208 173.668 ms 174.310 ms 173.999 ms > 18 216.200.241.66 172.504 ms 172.386 ms 172.700 ms > > > Tom > From owen at delong.com Mon Aug 6 17:55:19 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Aug 2012 15:55:19 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <50203FA1.8050503@ispalliance.net> References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> Message-ID: <12289110-9310-474C-8457-0E2C25562565@delong.com> That's simply not true at all... Let's look at what it takes to configure BGP as I suggested... 1. The ASN number of the two providers 2. The ASN to be used for the local side 3. The IP Address to use on the local end of each connection 4. The IP Address to peer with on each connection 5. The prefix(es) to be advertised. Of these 5, only items 2 and 5 have to come from the customer and the customer needs to provide both of these to both ISPs anyway for them to configure their side. It would be trivial for providers and CPE vendors to develop a standardized API by which a router could retrieve all 5 pieces of information for a given connection once that connection is plugged in to the router. It could literally be as simple as: 1. Port gets address via SLAAC or DHCP 2. Port retrieves XML configuration document from http://bgpconfig.local (or user-specified URL provided by ISP, or whatever) 6939 65512 192.0.2.21/30 2001:db8:1fea:93a9::1/64 192.0.2.22/30 2001:db8:1fea:93a9::2/64 203.0.113.0/24 198.51.100.0/24 0.0.0.0/0 (Yes, I realize that is a bit of an oversimplification of the XML syntax, but you get the idea) 3. Router configures port and BGP session according to received XML document, including appropriate prefix filters. 4. Router runs with that XML based configuration as long as link-state and power remain. That would allow a zeroconf BGP-enabled router in relatively small hardware accepting a default route that would work at least as well as today's dual-NAT based boxes. Note that BGP is not redesigned or even altered to achieve this. Since Linksys/DLink/Netgear/$EVERYONE already has web servers and clients embedded in their gear, the XML parser (or JSON or whatever they choose to use for standard encoding) would be pretty straight forward. Yes, the operator/provider has to do some additional configuration, but speaking as a network operator, I know that this can be automated because the management of BGP configurations, including the filters _IS_ that automated where I work. If the provider is telling the router which prefixes to permit announcement of through the configuration URL, then it's even more reliable, right? Owen On Aug 6, 2012, at 15:05 , Scott Helms wrote: > Owen, > > That's like saying if it were easy to fly we'd all be pilots, which isn't true either. BGP would need to be completely redesigned/replaced before it could possibly be automated to that level much less implemented by the Lynksis/DLink/Netgear/$yourfavoritesohorouter vendor. Business would need a reason to implement BGP and most simply don't AND BGP would have to be dramatically simpler and safer. Operators already have to be deeply involved (AKA filtering the announced networks) with edge network BGP implementations to prevent someone from announcing they're the preferred route for some other organization's netblock. This happens already on occasion and all of the people who run routers speaking BGP are generally professionals. > > On 8/6/2012 4:27 PM, Owen DeLong wrote: >> Respectfully, I disagree... I think this is a causal chain... >> >> 1. Lack of cost-effective BGP-based service means that >> 2. CPE vendors are not motivated to provide self-configuring bgp-speaking routers to behave in this manner means that >> 3. SMBs seek other solutions using available CPE technology. >> >> If cost-effective BGP-based service were available, providers would likely work with CPE vendors to get automation features added to products to support such services and multihomed organizations would definitely want to use those features. >> >> Owen >> >> On Aug 6, 2012, at 13:16 , Scott Helms wrote: >> >>> Probability is much too strong IMO. Most businesses don't even consider multi-homing and many that do use NAT devices with several connections rather than trying to run BGP. >>> >>> #not associated nor do I recommend, just an example >>> >>> http://www.fatpipeinc.com/warp/index.html >>> >>> >>>> This ignores the probability that cost effective BGP service availability would >>>> strongly drive demand for AS Numbers and adoption of the technology. >>>> >>>> Owen >>>> >>>> >>>> >>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >> > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- From paul4004 at gmail.com Mon Aug 6 17:57:16 2012 From: paul4004 at gmail.com (PC) Date: Mon, 6 Aug 2012 16:57:16 -0600 Subject: Wanted: Asia bandwidth test files In-Reply-To: <502040BA.1020403@cisco.com> References: <87zk6d899k.fsf@minnow.riseup.net> <502040BA.1020403@cisco.com> Message-ID: If you can, I suggest finding other well connected hosts and using IPERF in UDP mode for your testing. Separating TCP long-fat pipe and slow start issues from true packet delivery/loss rates at a given bitrate are beneficial. Use Linux as most iperf windows builds are based on cygwin and have issues at higher bitrates. On Mon, Aug 6, 2012 at 4:10 PM, Shishio Tsuchiya wrote: > Hi > I think RING project NLNOG has potential to help your effort. > https://ring.nlnog.net/ > At least they have location in tokyo. > > And I talked with Seichi Kawamura who is leader of JANOG about method of > quality verification among the world wide. > They are using host of Softlayer, amazon and OVH which could select the > location. > > Job and Mucho ccing. > > Regards, > -Shishio > > > (2012/08/03 2:59), Micah Anderson wrote: > > > > Hi, > > > > I'm sitting on what is advertised as a 100mbit/sec connection in > > Cambodia. I have been trying to verify that, because I do not believe it > > is valid. > > > > I did iperf tests from a number of network locations, and at one point I > > did get 71mbit/sec (most of the results were around 20-25mbit/sec or > > less). But I dont think 30 second iperf tests are particularly revealing > > when the bandwith rate might change drastically over the day. I > > considered doing a 3 day iperf test, but somehow this seems not how the > > tool was designed. > > > > Someone suggested I find test files from various Asian locations to > > download via wget. I found a bunch of 100mb test files for various > > providers in N. America and Europe on webhostingtalk, which were > > interesting, but I never got more than around 5mbit/sec with them. > > > > Does anyone have any machines in Japan, S. Korea, or other asian > > locations with good bandwidth. where they can host a 100mbit file so I > > can attempt to download it to test this? > > > > Other suggestions for reliable tests would also be welcome! Please, dont > > suggest some flash garbage :) > > > > thanks! > > micah > > > > > > From David.Wilde at aarnet.edu.au Mon Aug 6 18:08:26 2012 From: David.Wilde at aarnet.edu.au (David Wilde) Date: Mon, 6 Aug 2012 23:08:26 +0000 Subject: Wanted: Asia bandwidth test files In-Reply-To: <87zk6d899k.fsf@minnow.riseup.net> References: <87zk6d899k.fsf@minnow.riseup.net> Message-ID: <3AFB87B02BA2FE42B4EDEC3CDAFE58821B729782@SYD-VM-MBX1.ms.aarnet.edu.au> Hi Micah, You could try mirror.aarnet.edu.au, if Australia is sufficiently Asian for you... David -----Original Message----- From: Micah Anderson [mailto:micah at riseup.net] Sent: Friday, 3 August 2012 4:00 To: nanog at nanog.org Subject: Wanted: Asia bandwidth test files Hi, I'm sitting on what is advertised as a 100mbit/sec connection in Cambodia. I have been trying to verify that, because I do not believe it is valid. I did iperf tests from a number of network locations, and at one point I did get 71mbit/sec (most of the results were around 20-25mbit/sec or less). But I dont think 30 second iperf tests are particularly revealing when the bandwith rate might change drastically over the day. I considered doing a 3 day iperf test, but somehow this seems not how the tool was designed. Someone suggested I find test files from various Asian locations to download via wget. I found a bunch of 100mb test files for various providers in N. America and Europe on webhostingtalk, which were interesting, but I never got more than around 5mbit/sec with them. Does anyone have any machines in Japan, S. Korea, or other asian locations with good bandwidth. where they can host a 100mbit file so I can attempt to download it to test this? Other suggestions for reliable tests would also be welcome! Please, dont suggest some flash garbage :) thanks! micah -- From bill at herrin.us Mon Aug 6 18:15:26 2012 From: bill at herrin.us (William Herrin) Date: Mon, 6 Aug 2012 13:15:26 -1000 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <12289110-9310-474C-8457-0E2C25562565@delong.com> References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong wrote: > That's simply not true at all... > > Let's look at what it takes to configure BGP as I suggested... > > 1. The ASN number of the two providers > 2. The ASN to be used for the local side > 3. The IP Address to use on the local end of each connection > 4. The IP Address to peer with on each connection > 5. The prefix(es) to be advertised. Add to that: 6. Primary A, Primary B, Balanced (routing priority via AS path prepends) 7. Optional password for each session (some ISPs require one) Or take another tack: have the SOHO router accept a URL for each BGP connection and have the provider build the config. Then all you enter is your provider-assigned interface address, a DNS server address and a URL. Your point is well taken. A leaf node BGP configuration could be simplified to the point where it fits on a SOHO router config page and does not require an expert to configure. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Mon Aug 6 18:36:40 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 06 Aug 2012 16:36:40 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: <50205508.1040406@rollernet.us> On 8/6/12 4:15 PM, William Herrin wrote: > On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong wrote: >> That's simply not true at all... >> >> Let's look at what it takes to configure BGP as I suggested... >> >> 1. The ASN number of the two providers >> 2. The ASN to be used for the local side >> 3. The IP Address to use on the local end of each connection >> 4. The IP Address to peer with on each connection >> 5. The prefix(es) to be advertised. > > Add to that: > > 6. Primary A, Primary B, Balanced (routing priority via AS path prepends) > 7. Optional password for each session (some ISPs require one) > > Or take another tack: have the SOHO router accept a URL for each BGP > connection and have the provider build the config. Then all you enter > is your provider-assigned interface address, a DNS server address and > a URL. > > Your point is well taken. A leaf node BGP configuration could be > simplified to the point where it fits on a SOHO router config page and > does not require an expert to configure. > This is all being approached from the wrong angle; there's too much technical talk. "BGP to the Home" needs to be sales/marketing driven. (You're allowed to use buzzwords with no actual meaning though.) ~Seth From owen at delong.com Mon Aug 6 18:38:57 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Aug 2012 16:38:57 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: <77DB70B8-CE7A-48F4-9393-E17C0005EE1F@delong.com> On Aug 6, 2012, at 16:15 , William Herrin wrote: > On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong wrote: >> That's simply not true at all... >> >> Let's look at what it takes to configure BGP as I suggested... >> >> 1. The ASN number of the two providers >> 2. The ASN to be used for the local side >> 3. The IP Address to use on the local end of each connection >> 4. The IP Address to peer with on each connection >> 5. The prefix(es) to be advertised. > > Add to that: > > 6. Primary A, Primary B, Balanced (routing priority via AS path prepends) Not absolutely required and certainly going beyond what is required to provide slightly better than the functionality provided with the dual-NAT scenario. > 7. Optional password for each session (some ISPs require one) Fair enough, but pretty trivial. > > Or take another tack: have the SOHO router accept a URL for each BGP > connection and have the provider build the config. Then all you enter > is your provider-assigned interface address, a DNS server address and > a URL. Well, I was going for zeroconf, but yes, that was basically allowed for in what I described. > > Your point is well taken. A leaf node BGP configuration could be > simplified to the point where it fits on a SOHO router config page and > does not require an expert to configure. > Yep... And it could even be made 100% automated zeroconf with a little more effort. It could even use provider-assigned private-ASNs and a shared PA prefix with a little additional ingenuity. Owen From hvgeekwtrvl at gmail.com Mon Aug 6 18:42:55 2012 From: hvgeekwtrvl at gmail.com (james machado) Date: Mon, 6 Aug 2012 16:42:55 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <12289110-9310-474C-8457-0E2C25562565@delong.com> References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: On Mon, Aug 6, 2012 at 3:55 PM, Owen DeLong wrote: > That's simply not true at all... > > Let's look at what it takes to configure BGP as I suggested... > > 1. The ASN number of the two providers > 2. The ASN to be used for the local side > 3. The IP Address to use on the local end of each connection > 4. The IP Address to peer with on each connection > 5. Te prefix(es) to be advertised. > > Of these 5, only items 2 and 5 have to come from the customer and the customer needs to provide both of these to both ISPs anyway for them to configure their side. > > It would be trivial for providers and CPE vendors to develop a standardized API by which a router could retrieve all 5 pieces of information for a given connection once that connection is plugged in to the router. It could literally be as simple as: > > 1. Port gets address via SLAAC or DHCP > 2. Port retrieves XML configuration document from http://bgpconfig.local (or user-specified URL provided by ISP, or whatever) > > 6939 > 65512 > 192.0.2.21/30 > 2001:db8:1fea:93a9::1/64 > 192.0.2.22/30 > 2001:db8:1fea:93a9::2/64 > > 203.0.113.0/24 > 198.51.100.0/24 > 0.0.0.0/0 > > > > (Yes, I realize that is a bit of an oversimplification of the XML syntax, but you get the idea) > > 3. Router configures port and BGP session according to received XML document, including > appropriate prefix filters. > > 4. Router runs with that XML based configuration as long as link-state and power remain. > > That would allow a zeroconf BGP-enabled router in relatively small hardware accepting a default route that would work at least as well as today's dual-NAT based boxes. Note that BGP is not redesigned or even altered to achieve this. Since Linksys/DLink/Netgear/$EVERYONE already has web servers and clients embedded in their gear, the XML parser (or JSON or whatever they choose to use for standard encoding) would be pretty straight forward. > >From a SMB perspective this is part of the problem. Why pay for: 1. An ASN 2. 2 BGP connections 3. PI space 4. More expensive hardware (potentially and probably) when I'm only going to get a Default Route? I've added complexity to my life, administrative and OPEX overhead when I'm getting no benefits of BGP other than a default route. I can get a default route from a provider without adding complexity and overhead. An SMB who does not have a staff on hand wants it cheap and to work. Everything else is a potential expense they don't want to spend. They don't want to have to call either their support company or vendor because the "Internet is down", at most they want to pull the power on the router and plug it back in and have it all work. At best they want to only know what that "little black box with the blinky lights" is when someone packs it into a box because it's wasting power and now the "Internet is broken". >From an SMB who has a staff on hand it still may not be worth it if they don't have someone who is BGP smart. And truth to tell *you* don't want more BGP idiots polluting the routing table either intentionally or unintentionally. Conversely if you do make BGP that available to SMB's and home users (not necessarily a bad thing) the issues with routing table size has to be dealt with. Right now there are roughly 42K ASes with routes in the routing table. Add SMB's and home users and your looking at potentially millions of ASes with routes in the routing table. Heck if you *only* double the ASes and associated routes many many routers are going to crash and need replacement. > Yes, the operator/provider has to do some additional configuration, but speaking as a network operator, I know that this can be automated because the management of BGP configurations, including the filters _IS_ that automated where I work. If the provider is telling the router which prefixes to permit announcement of through the configuration URL, then it's even more reliable, right? > > Owen > > On Aug 6, 2012, at 15:05 , Scott Helms wrote: > >> Owen, >> >> That's like saying if it were easy to fly we'd all be pilots, which isn't true either. BGP would need to be completely redesigned/replaced before it could possibly be automated to that level much less implemented by the Lynksis/DLink/Netgear/$yourfavoritesohorouter vendor. Business would need a reason to implement BGP and most simply don't AND BGP would have to be dramatically simpler and safer. Operators already have to be deeply involved (AKA filtering the announced networks) with edge network BGP implementations to prevent someone from announcing they're the preferred route for some other organization's netblock. This happens already on occasion and all of the people who run routers speaking BGP are generally professionals. >> >> On 8/6/2012 4:27 PM, Owen DeLong wrote: >>> Respectfully, I disagree... I think this is a causal chain... >>> >>> 1. Lack of cost-effective BGP-based service means that >>> 2. CPE vendors are not motivated to provide self-configuring bgp-speaking routers to behave in this manner means that >>> 3. SMBs seek other solutions using available CPE technology. >>> >>> If cost-effective BGP-based service were available, providers would likely work with CPE vendors to get automation features added to products to support such services and multihomed organizations would definitely want to use those features. >>> >>> Owen >>> >>> On Aug 6, 2012, at 13:16 , Scott Helms wrote: >>> >>>> Probability is much too strong IMO. Most businesses don't even consider multi-homing and many that do use NAT devices with several connections rather than trying to run BGP. >>>> >>>> #not associated nor do I recommend, just an example >>>> >>>> http://www.fatpipeinc.com/warp/index.html >>>> >>>> >>>>> This ignores the probability that cost effective BGP service availability would >>>>> strongly drive demand for AS Numbers and adoption of the technology. >>>>> >>>>> Owen >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Scott Helms >>>> Vice President of Technology >>>> ZCorum >>>> (678) 507-5000 >>>> -------------------------------- >>>> http://twitter.com/kscotthelms >>>> -------------------------------- >>>> >>> >> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- > > james From aftab.siddiqui at gmail.com Mon Aug 6 18:56:15 2012 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 7 Aug 2012 04:56:15 +0500 Subject: Wanted: Asia bandwidth test files In-Reply-To: <3AFB87B02BA2FE42B4EDEC3CDAFE58821B729782@SYD-VM-MBX1.ms.aarnet.edu.au> References: <87zk6d899k.fsf@minnow.riseup.net> <3AFB87B02BA2FE42B4EDEC3CDAFE58821B729782@SYD-VM-MBX1.ms.aarnet.edu.au> Message-ID: Hi Micah > Does anyone have any machines in Japan, S. Korea, or other asian locations with good bandwidth. where they can host a 100mbit file so I can attempt to download it to test this? > you may try downloading from stingray.cyber.net.pk It's in Karachi (Pakistan) with GigE limits. Use rsync. Regards, Aftab A. Siddiqui. -- Regards, Aftab A. Siddiqui From leschnik at gmail.com Mon Aug 6 19:54:59 2012 From: leschnik at gmail.com (Jason Leschnik) Date: Tue, 7 Aug 2012 10:54:59 +1000 Subject: Wanted: Asia bandwidth test files In-Reply-To: References: <87zk6d899k.fsf@minnow.riseup.net> <3AFB87B02BA2FE42B4EDEC3CDAFE58821B729782@SYD-VM-MBX1.ms.aarnet.edu.au> Message-ID: I find the mirrors here are generally beefy https://launchpad.net/ubuntu/+archivemirrors Thanks. On Tuesday, August 7, 2012, Aftab Siddiqui wrote: > Hi Micah > > > Does anyone have any machines in Japan, S. Korea, or other asian > locations with good bandwidth. where they can host a 100mbit file so I can > attempt to download it to test this? > > > > you may try downloading from stingray.cyber.net.pk > It's in Karachi (Pakistan) with GigE limits. Use rsync. > > Regards, > > Aftab A. Siddiqui. > > -- > Regards, > > Aftab A. Siddiqui > -- Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik ansto dot gov dot au [U@] jml974 at uow.edu.au From dholmes at mwdh2o.com Mon Aug 6 19:55:18 2012 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 6 Aug 2012 17:55:18 -0700 Subject: Cisco 7200 PCI Limitations In-Reply-To: References: <501B7F86.1090709@shthead.com> Message-ID: <922ACC42D498884AA02B3565688AF99537BEC06FBD@USEXMBS01.mwd.h2o> For users with private DS3-based network links between sites, for the case where 2 or more of these DS3's are to be bundled together in a multi-link PPP connection, Cisco will not support this configuration due to insufficient 7200 cpu resources, so packet-by-packet load sharing must be used which could result in packets arriving out of sequence. Cisco will not support VoIP over packet-by-packet load sharing. Additionally, PIM multicast uses only a single DS3 under the packet-by-packet load sharing scenario, so all available bandwidth with 2 or more DS3s is not available. The 7200 will support 8 T1s in a logical multilink bundle, though, so for low speed circuits, the 7200 still provides complete IOS feature functionality. The 7200s have some very limited uses, but in my view they have no place in today's wire speed backbone networks, particularly when 3 or more 7200 GiGE interfaces can be used as a logical bundle. The biggest problem is the tendency of some to treat the 7200 as an Ethernet switch, define a portchannel with 2 or more GiGE interfaces, connect the 7200 portchannel to a modern Ethernet switch, and by this action define a network bottleneck where packets can be dropped due to a serious backplane/wire speed mismatch. -----Original Message----- From: PC [mailto:paul4004 at gmail.com] Sent: Monday, August 06, 2012 10:05 AM To: david peahi Cc: nanog at nanog.org Subject: Re: Cisco 7200 PCI Limitations While I agree it may not be suitable for transit GigE purposes, it is certainly acceptable for many WAN aggregation scenarios and CPE scenarios well in excess of T1 speeds. There are still many out there in DS3, Fast-E, subrate ethernet subscriber, ATM, (DSL/L2TP/PPPOE), DMVPN, and other similar scenarios. For this, while often not ideal, they continue to work fine. On Mon, Aug 6, 2012 at 10:47 AM, david peahi wrote: > The 7200 architecture dates from the late 1990s, and is basically modeled > on a PCI-bus UNIX workstation from that era. The 7200 is usable today as a > WAN aggregation router for T1 access, and nothing else. Using it as a GiGE > transit router will place a non-deterministic node in the network, unable > to scale to the 4 GiGE full-duplex throughput. Even worse is creating a > portchannel out of the 7200 GiGE interfaces and using dot1q sub-interfaces > to emulate an Ethernet switch in 7200 software, then connecting the 7200 > dot1q trunk to a modern Ethernet switch with a wire speed backplane (for > example a Cisco 3560X Ethernet switch). > Long since considered an unacceptable best practice (due to the 7200 > backplane limitation vs adjacent, directly connected modern Ethernet > switches), Cisco is still teaching portchannel in its router configuration > classes, so relatively new network engineers have actually been known to > use this ill-considered configuration. > If a 4 port GiGE Cisco router is needed, then the ASR1001 is the modern > version of the 7206, with wire speed throughput. > > On Fri, Aug 3, 2012 at 12:36 AM, shthead wrote: > > > Hi all, > > > > I have a 7200 series router (7204) here and I am trying to figure out > > something with it. Currently the router has a NPE-G1 card in it, giving > it > > 3 gig interfaces but I need an extra gig interface on it to make 4. > > > > Having a look around the available options are either get a PA-GE card > > that fits into one of the slots on the router or to get a C7200-I/O-GE+E > > (I/O controller with a gbit port on it). > > > > The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus > > will limit it to 300mbit full duplex (and it goes on further to say it > will > > be limited to approx 200mbit in best case scenario due to the design of > the > > card) [1]. > > > > The other option left is the I/O controller. I found that you can get a > > port adaptor jacket card [2] for the 7200's that let you stick a normal > > interface card into the I/O controller slot (instead of the I/O > controller > > itself). > > > > My main concern is if the jacket card uses its own PCI bus I am assuming > > the C7200-I/O-GE+E also connects via PCI which means it would be subject > to > > the same limitations as the PA-GE. > > > > Does anyone have any idea if that would be correct and the only option > for > > another gbit port would be to get another device? > > > > Thanks for the help > > > > [1] http://www.cisco.com/en/US/**products/hw/routers/ps341/** > > products_tech_**note09186a00800c814a.shtml#**backinfo< > http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note09186a00800c814a.shtml#backinfo > > > > [2] http://www.cisco.com/en/US/**prod/collateral/routers/ps341/** > > prod_qas0900aecd8045055e.html< > http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_qas0900aecd8045055e.html > > > > > > > This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From owen at delong.com Mon Aug 6 20:04:35 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Aug 2012 18:04:35 -0700 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: On Aug 6, 2012, at 16:42 , james machado wrote: > On Mon, Aug 6, 2012 at 3:55 PM, Owen DeLong wrote: >> That's simply not true at all... >> >> Let's look at what it takes to configure BGP as I suggested... >> >> 1. The ASN number of the two providers >> 2. The ASN to be used for the local side >> 3. The IP Address to use on the local end of each connection >> 4. The IP Address to peer with on each connection >> 5. Te prefix(es) to be advertised. >> >> Of these 5, only items 2 and 5 have to come from the customer and the customer needs to provide both of these to both ISPs anyway for them to configure their side. >> >> It would be trivial for providers and CPE vendors to develop a standardized API by which a router could retrieve all 5 pieces of information for a given connection once that connection is plugged in to the router. It could literally be as simple as: >> >> 1. Port gets address via SLAAC or DHCP >> 2. Port retrieves XML configuration document from http://bgpconfig.local (or user-specified URL provided by ISP, or whatever) >> >> 6939 >> 65512 >> 192.0.2.21/30 >> 2001:db8:1fea:93a9::1/64 >> 192.0.2.22/30 >> 2001:db8:1fea:93a9::2/64 >> >> 203.0.113.0/24 >> 198.51.100.0/24 >> 0.0.0.0/0 >> >> >> >> (Yes, I realize that is a bit of an oversimplification of the XML syntax, but you get the idea) >> >> 3. Router configures port and BGP session according to received XML document, including >> appropriate prefix filters. >> >> 4. Router runs with that XML based configuration as long as link-state and power remain. >> >> That would allow a zeroconf BGP-enabled router in relatively small hardware accepting a default route that would work at least as well as today's dual-NAT based boxes. Note that BGP is not redesigned or even altered to achieve this. Since Linksys/DLink/Netgear/$EVERYONE already has web servers and clients embedded in their gear, the XML parser (or JSON or whatever they choose to use for standard encoding) would be pretty straight forward. >> > >> From a SMB perspective this is part of the problem. Why pay for: > > 1. An ASN > 2. 2 BGP connections > 3. PI space > 4. More expensive hardware (potentially and probably) > 1-3 are optional and not required for what I proposed. You could do it with a private ASN, PA space and an LOA if you don't care about provider mobility. I would argue that 4 assumes facts not in evidence. > when I'm only going to get a Default Route? I've added complexity to > my life, administrative and OPEX overhead when I'm getting no benefits > of BGP other than a default route. I can get a default route from a > provider without adding complexity and overhead. > The goal here was to make this as simple and cost-effective as the NAT-based IPv4 solution currently in common use. There's no reason it can't be exactly that. It does provide advantages over the NAT-based solution (sessions can survive failover). You certainly have the option of a more complex BGP configuration, but that does require a more expensive router and probably 1-3 as well. > An SMB who does not have a staff on hand wants it cheap and to work. Which is why I proposed a mechanism by which it could be zero-configuration, zero additional cost, and provide only marginal benefits over the current IPv4 configuration while also supporting IPv6. > Everything else is a potential expense they don't want to spend. They > don't want to have to call either their support company or vendor > because the "Internet is down", at most they want to pull the power on > the router and plug it back in and have it all work. At best they > want to only know what that "little black box with the blinky lights" > is when someone packs it into a box because it's wasting power and now > the "Internet is broken". Right... I believe what I proposed comes as close to that as current SOHO routers that are in common use in the SMB world. > >> From an SMB who has a staff on hand it still may not be worth it if > they don't have someone who is BGP smart. And truth to tell *you* > don't want more BGP idiots polluting the routing table either > intentionally or unintentionally. > No BGP expertise required... Look again at what I proposed... All configuration of the BGP is done automatically and dictated by the ISP. > Conversely if you do make BGP that available to SMB's and home users > (not necessarily a bad thing) the issues with routing table size has > to be dealt with. Right now there are roughly 42K ASes with routes in > the routing table. Add SMB's and home users and your looking at > potentially millions of ASes with routes in the routing table. Heck > if you *only* double the ASes and associated routes many many routers > are going to crash and need replacement. First, that's not an unsolvable problem and it's a crying shame that the IETF punted on it instead of solving it as part of the IPv6 design. Second, I think most of these would be stub-AS using private ASNs mapped into their upstream providers AS. Yes, it will add prefixes, but anyone who multihomes today is going to end up being a prefix in IPv6. Overall, I'd say that's a problem we have to solve one way or another. Owen > > >> Yes, the operator/provider has to do some additional configuration, but speaking as a network operator, I know that this can be automated because the management of BGP configurations, including the filters _IS_ that automated where I work. If the provider is telling the router which prefixes to permit announcement of through the configuration URL, then it's even more reliable, right? >> >> Owen >> >> On Aug 6, 2012, at 15:05 , Scott Helms wrote: >> >>> Owen, >>> >>> That's like saying if it were easy to fly we'd all be pilots, which isn't true either. BGP would need to be completely redesigned/replaced before it could possibly be automated to that level much less implemented by the Lynksis/DLink/Netgear/$yourfavoritesohorouter vendor. Business would need a reason to implement BGP and most simply don't AND BGP would have to be dramatically simpler and safer. Operators already have to be deeply involved (AKA filtering the announced networks) with edge network BGP implementations to prevent someone from announcing they're the preferred route for some other organization's netblock. This happens already on occasion and all of the people who run routers speaking BGP are generally professionals. >>> >>> On 8/6/2012 4:27 PM, Owen DeLong wrote: >>>> Respectfully, I disagree... I think this is a causal chain... >>>> >>>> 1. Lack of cost-effective BGP-based service means that >>>> 2. CPE vendors are not motivated to provide self-configuring bgp-speaking routers to behave in this manner means that >>>> 3. SMBs seek other solutions using available CPE technology. >>>> >>>> If cost-effective BGP-based service were available, providers would likely work with CPE vendors to get automation features added to products to support such services and multihomed organizations would definitely want to use those features. >>>> >>>> Owen >>>> >>>> On Aug 6, 2012, at 13:16 , Scott Helms wrote: >>>> >>>>> Probability is much too strong IMO. Most businesses don't even consider multi-homing and many that do use NAT devices with several connections rather than trying to run BGP. >>>>> >>>>> #not associated nor do I recommend, just an example >>>>> >>>>> http://www.fatpipeinc.com/warp/index.html >>>>> >>>>> >>>>>> This ignores the probability that cost effective BGP service availability would >>>>>> strongly drive demand for AS Numbers and adoption of the technology. >>>>>> >>>>>> Owen >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Scott Helms >>>>> Vice President of Technology >>>>> ZCorum >>>>> (678) 507-5000 >>>>> -------------------------------- >>>>> http://twitter.com/kscotthelms >>>>> -------------------------------- >>>>> >>>> >>> >>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >> >> > > > > james From fernando at gont.com.ar Mon Aug 6 20:17:00 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Mon, 06 Aug 2012 22:17:00 -0300 Subject: IPv6 Toolkit v1.2.2 released Message-ID: <50206C8C.6020900@gont.com.ar> Folks, We've released IPv6 toolkit version 1.2.2. It is available at: (tarball and git repository). This version is meant to be fully-portable to Mac OS (the list of supported systems now including, at the very least, FreeBSD, NetBSD, OpenBSD, Linux, and Mac OS), and also incorporates a number of patches send by the community. Any feedback on the tools will be welcome (either unicast to me, or on the ipv6hackers mailing-list ). P.S.: If you've sent patches and your patches have not yet been applied, most likely it just means that I'm catching-up with them (feel free to resend!). Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From aj at jonesy.com.au Mon Aug 6 21:40:20 2012 From: aj at jonesy.com.au (Andrew Jones) Date: Tue, 07 Aug 2012 12:40:20 +1000 Subject: NFSen plugin - ddd In-Reply-To: <20120805230856.GA55456@DataIX.net> References: <49f9d2ec16de2c67b51a0229dcf18510@localhost> <20120805230856.GA55456@DataIX.net> Message-ID: <51cd90256dc62e6de54aa3a7d1f49f70@localhost> I did manage to get my hands on it this morning (thanks Brandon!). I've put it up for anyone who's interested [1], I had a couple of people ask for a copy if I found it. I haven't had a chance to look through the plugin yet, so take no responsibility for it. Cheers, Jonesy [1] http://www.haqthegibson.com/files/ddd.zip On Sun, 5 Aug 2012 19:08:56 -0400, Jason Hellenthal wrote: > Don't know if you ever recieved a reply for this but this is the best I > have come up with to get more eyes on it. > > http://sourceforge.net/apps/trac/nfsen-plugins/wiki/RequestPlugin > > I have not submitted a request for it but if you happen to come accross > this plugin, I would be interested. > > On Fri, Aug 03, 2012 at 01:55:21PM +1000, Andrew Jones wrote: >> Hi All, >> Does anyone have a copy of the DDoS detection plugin for NFSen called ddd >> that they could send to me? >> According to a blog article [1] I read, it used to be available at [2]. >> It's not there, and I haven't had any luck trying to track it down the >> usual ways. If anyone is able to provide a copy, I'd appreciate it. >> Thanks, >> Jonesy >> >> >> [1] http://www.ccieflyer.com/2010-01-JasonRowley.php >> [2] http://www.synacknetworks.com/ddd/ddd.zip From me at anuragbhatia.com Tue Aug 7 00:08:24 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 7 Aug 2012 01:08:24 -0400 Subject: Trouble with IPv6 setup on Quagga Message-ID: Hello everyone I am having trouble with Quagga in setting up IPv6 BGP. So far it was failing with external providers. Just now I gave it a try to setup BGP session (IPv6 only) within our ASN between two routers. >From our other end router I see there is no acconcement, while I see blocks being announced via Quagga. Also strange enough is that the number of blocks I account - they all come as "withdrawl routes" on other router as soon as Quagga is turned on. E.g this is what I see on Quagga: node4# show bgp ipv6 summary BGP router identifier 199.116.78.28, local AS number 54456 RIB entries 18741, using 1757 KiB of memory Peers 1, using 4560 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2607:1b00:10:a::1 4 54456 6865 5 0 0 0 00:00:05 9798 Total number of neighbors 1 node4# So BGP session is up. Next if I check advertised routes, it goes like: node4# show bgp ipv6 neighbors 2607:1b00:10:a::1 advertised-routes BGP table version is 0, local router ID is 199.116.78.28 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 2607:1b00:d1::/48 :: 0 100 32768 i *> 2607:1b00:d2::/48 :: 0 100 32768 i Total number of prefixes 2 node4# I don't see these routes in other router at all. Here's what my Quagga bgpd.conf looks like: hostname node4 timers bgp 4 16 router bgp 54456 bgp router-id 199.116.78.28 redistribute connected metric 1 redistribute static metric 1 neighbor 2607:1b00:10:a::1 remote-as 54456 neighbor 2607:1b00:10:a::1 next-hop-self address-family ipv6 network 2607:1b00:d1::/48 network 2607:1b00:d2::/48 neighbor 2607:1b00:10:a::1 activate exit-address-family Was wondering if someone can point in me right direction since both of these prefixes are (annnounced and ?) withdrawn as soon as I restart Quagga. Thanks. -- Anurag Bhatia Web: anuragbhatia.com Skype: anuragbhatia.com Linkedin | Twitter| Google+ From mch-nanog at xs4all.nl Tue Aug 7 03:51:48 2012 From: mch-nanog at xs4all.nl (Marco Hogewoning) Date: Tue, 7 Aug 2012 10:51:48 +0200 Subject: Trouble with IPv6 setup on Quagga In-Reply-To: References: Message-ID: > I am having trouble with Quagga in setting up IPv6 BGP. So far it was > failing with external providers. Just now I gave it a try to setup BGP > session (IPv6 only) within our ASN between two routers. > > From our other end router I see there is no acconcement, while I see blocks > being announced via Quagga. Also strange enough is that the number of > blocks I account - they all come as "withdrawl routes" on other router as > soon as Quagga is turned on. I recall some issues with the value of the next-hop in the BGP messages in the past. Haven't been around Quagga in recent times, don't know if this is still the case. If possible you might want to catch a BGP packet with tcpdump and verify the value in there makes sense to the other side. Got bitten by this before and took me ages to figure out the other side was dropping my updates because the next-hop couldn't be resolved. Marco From tom at ninjabadger.net Tue Aug 7 04:35:10 2012 From: tom at ninjabadger.net (tom at ninjabadger.net) Date: Tue, 7 Aug 2012 10:35:10 +0100 (BST) Subject: Trouble with IPv6 setup on Quagga In-Reply-To: References: Message-ID: <06c38bf84f499b87d1c814239c081b6c.squirrel@g.mail.aa.net.uk> Hi Anurag, > node4# show bgp ipv6 neighbors 2607:1b00:10:a::1 advertised-routes > BGP table version is 0, local router ID is 199.116.78.28 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale, R Removed > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > *> 2607:1b00:d1::/48 > :: 0 100 32768 i > *> 2607:1b00:d2::/48 > :: 0 100 32768 i > > Total number of prefixes 2 TH: That next-hop does look suspect. If they're on the same subnet, try disabling next-hop-self. It will just use link-local addressing on the foreign side, should the next hop be unreachable. It could be that with next-hop-self configured and no IPv6 address on lo, this isn't working correctly. Do you have a global address on lo? > Here's what my Quagga bgpd.conf looks like: > > hostname node4 > timers bgp 4 16 > > router bgp 54456 > bgp router-id 199.116.78.28 > redistribute connected metric 1 > redistribute static metric 1 TH: One thing you should add for sanity: no bgp default ipv4-unicast Otherwise Quagga will default to advertising IPv4 address family via IPv6 neighbors. 'bgp network import-check' is also useful to ensure Quagga behaves in the same way as a Cisco/Juniper router when it comes to advertisements (this goes for both address families). > neighbor 2607:1b00:10:a::1 remote-as 54456 > neighbor 2607:1b00:10:a::1 next-hop-self > > address-family ipv6 > network 2607:1b00:d1::/48 > network 2607:1b00:d2::/48 > neighbor 2607:1b00:10:a::1 activate > exit-address-family TH: This looks fine otherwise. Tom From tom at ninjabadger.net Tue Aug 7 04:38:16 2012 From: tom at ninjabadger.net (tom at ninjabadger.net) Date: Tue, 7 Aug 2012 10:38:16 +0100 (BST) Subject: next hop packet loss In-Reply-To: References: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> <50203C33.9040506@ninjabadger.net> Message-ID: <5be2f848f21f8348447f2e4fc9738420.squirrel@g.mail.aa.net.uk> Well, you haven't provided any proof of that. Their website works just fine for me (TM). Since your troubleshooting is limited to methods that are blocked by Checkpoint's network, you might need to revisit how you're going about diagnosing the problem you're facing. In any case, I won't be providing any further input following that response. Tom > It is a problem with http protocol regardless of ICMP. > > Sent from my iPhone > > On Aug 6, 2012, at 5:51 PM, "Tom Hill" wrote: > >> Hi Jim, >> >> On 06/08/12 22:27, Jim Ray wrote: >>> What is the best way to solve this type of problem? >> >> It's not a problem, it's checkpoint purporting to be 'secure' when all >> they're doing is blocking ICMP outright, seemingly. >> >> If I try 'tcptraceroute' (from Linux) it works just fine, bare the >> Above.net hop in the middle that doesn't respond - ignore. >> >> $ sudo tcptraceroute -n checkpoint.com >> traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte >> packets >> 1 81.187.203.81 0.719 ms 1.050 ms 1.298 ms >> 2 90.155.53.54 30.184 ms 31.604 ms 32.370 ms >> 3 90.155.53.43 33.891 ms 35.072 ms 36.021 ms >> 4 85.91.238.217 37.016 ms 38.236 ms 39.215 ms >> 5 85.91.224.10 40.226 ms 41.358 ms 42.354 ms >> 6 212.187.200.145 164.713 ms 164.102 ms 164.020 ms >> 7 4.69.139.99 45.316 ms 194.042 ms 194.088 ms >> 8 64.125.14.17 194.297 ms 193.943 ms 193.558 ms >> 9 64.125.31.198 194.304 ms 194.462 ms 193.560 ms >> 10 * * * >> 11 64.125.26.37 288.267 ms 284.237 ms 166.340 ms >> 12 64.125.24.38 178.571 ms 179.467 ms 156.769 ms >> 13 64.125.28.238 148.002 ms 147.244 ms 147.501 ms >> 14 64.125.26.141 206.010 ms 205.574 ms 205.426 ms >> 15 64.125.28.57 201.753 ms 172.439 ms 174.169 ms >> 16 64.124.201.230 176.866 ms 172.412 ms 172.510 ms >> 17 208.185.174.208 173.668 ms 174.310 ms 173.999 ms >> 18 216.200.241.66 172.504 ms 172.386 ms 172.700 ms >> >> >> Tom >> > From eugen at leitl.org Tue Aug 7 07:25:09 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 7 Aug 2012 14:25:09 +0200 Subject: raging bulls Message-ID: <20120807122509.GC12615@leitl.org> http://www.wired.com/business/2012/08/ff_wallstreet_trading/all/ Some interesting, network-relevant content there (but for the neutrino and drone rubbish). From jim at neuse.net Tue Aug 7 08:12:02 2012 From: jim at neuse.net (Jim Ray) Date: Tue, 7 Aug 2012 09:12:02 -0400 Subject: next hop packet loss In-Reply-To: <5be2f848f21f8348447f2e4fc9738420.squirrel@g.mail.aa.net.uk> References: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> <50203C33.9040506@ninjabadger.net> <5be2f848f21f8348447f2e4fc9738420.squirrel@g.mail.aa.net.uk> Message-ID: <530DFF0280267643A67908BB181189E5981DE9@garcia.neuse.local> Sorry, I do not give verbose responses via iPhone on that small device with my tired old eyes. I ran Wireshark this morning. Without sniffing packets, the layman's description of problem is "I can't get to vendor web site, http://www.CheckPoint.com, on Time Warner Business Class network I use." Hence, http is blocked in addition to ICMP. It is what it is. Personally, I plan to use the phone to reach Check Point since TCP/IP won't work. I also got call back from top local executive at Time Warner this morning that has known me 17 years, understands the problem and is trying to help. Again, no emergency here. Still, I would like it to work and pay extra to have the commercial connection with service level agreement. Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com -----Original Message----- From: tom at ninjabadger.net [mailto:tom at ninjabadger.net] Sent: Tuesday, August 07, 2012 5:38 AM To: Jim Ray Cc: Tom Hill; nanog at nanog.org Subject: Re: next hop packet loss Well, you haven't provided any proof of that. Their website works just fine for me (TM). Since your troubleshooting is limited to methods that are blocked by Checkpoint's network, you might need to revisit how you're going about diagnosing the problem you're facing. In any case, I won't be providing any further input following that response. Tom > It is a problem with http protocol regardless of ICMP. > > Sent from my iPhone > > On Aug 6, 2012, at 5:51 PM, "Tom Hill" wrote: > >> Hi Jim, >> >> On 06/08/12 22:27, Jim Ray wrote: >>> What is the best way to solve this type of problem? >> >> It's not a problem, it's checkpoint purporting to be 'secure' when >> all they're doing is blocking ICMP outright, seemingly. >> >> If I try 'tcptraceroute' (from Linux) it works just fine, bare the >> Above.net hop in the middle that doesn't respond - ignore. >> >> $ sudo tcptraceroute -n checkpoint.com traceroute to checkpoint.com >> (216.200.241.66), 30 hops max, 60 byte packets >> 1 81.187.203.81 0.719 ms 1.050 ms 1.298 ms >> 2 90.155.53.54 30.184 ms 31.604 ms 32.370 ms >> 3 90.155.53.43 33.891 ms 35.072 ms 36.021 ms >> 4 85.91.238.217 37.016 ms 38.236 ms 39.215 ms >> 5 85.91.224.10 40.226 ms 41.358 ms 42.354 ms >> 6 212.187.200.145 164.713 ms 164.102 ms 164.020 ms >> 7 4.69.139.99 45.316 ms 194.042 ms 194.088 ms >> 8 64.125.14.17 194.297 ms 193.943 ms 193.558 ms >> 9 64.125.31.198 194.304 ms 194.462 ms 193.560 ms >> 10 * * * >> 11 64.125.26.37 288.267 ms 284.237 ms 166.340 ms >> 12 64.125.24.38 178.571 ms 179.467 ms 156.769 ms >> 13 64.125.28.238 148.002 ms 147.244 ms 147.501 ms >> 14 64.125.26.141 206.010 ms 205.574 ms 205.426 ms >> 15 64.125.28.57 201.753 ms 172.439 ms 174.169 ms >> 16 64.124.201.230 176.866 ms 172.412 ms 172.510 ms >> 17 208.185.174.208 173.668 ms 174.310 ms 173.999 ms >> 18 216.200.241.66 172.504 ms 172.386 ms 172.700 ms >> >> >> Tom >> > From BECHA at ripe.net Tue Aug 7 09:13:07 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 07 Aug 2012 16:13:07 +0200 Subject: Prefix Size Distribution in multiple flavors, on RIPEstat Message-ID: <50212273.6010301@ripe.net> Dear colleagues, thanks to the feedback we received after we've published the interactive widget for querying "RIR prefix size distribution" in RIPEstat, we created a follow-up: a dynamically updated web page that gives an overview of IPv4 address space prefix size distribution, per /8: https://stat.ripe.net/specials/registered-ipv4-prefix-size-distribution This page is updated once a day, and is based on statistics published by all 5 RIRs. Possible usage is general research about the distribution of address space, or prefix filtering based on minimum allocation size. If you want to query any other prefix size, and not only /8, or if you want to query for IPv6 space, here is the link to the widget: https://stat.ripe.net/widget/rir-prefix-size-distribution For the background, please find more information in RIPE Labs article about the widget: https://labs.ripe.net/Members/becha/rir-prefix-size-distribution-in-ripestat Looking forward to your comments or questions, regards, Vesna -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net From bill at herrin.us Tue Aug 7 09:50:43 2012 From: bill at herrin.us (William Herrin) Date: Tue, 7 Aug 2012 04:50:43 -1000 Subject: next hop packet loss In-Reply-To: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> References: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> Message-ID: On Mon, Aug 6, 2012 at 11:27 AM, Jim Ray wrote: > I have a Time Warner Business Class connection and am unable to reach > http://www.checkpoint.com to research product line I wish to carry. I > did a trace route and confirmed packets are past my network, Time Warner > network and onto next hop where they execute jump to nowhere > instruction. > Here is the tracert just now (it has been failing for weeks): That's an artifact of Checkpoint blocking pings. Note the difference between ICMP and TCP-based traceroutes: traceroute -I 216.200.241.66 traceroute to 216.200.241.66 (216.200.241.66), 30 hops max, 60 byte packets 1 sark.dirtside.com (70.182.189.216) 0.462 ms 0.494 ms 0.555 ms 2 10.1.192.1 (10.1.192.1) 9.023 ms 9.197 ms 9.247 ms 3 ip72-196-255-1.dc.dc.cox.net (72.196.255.1) 15.210 ms 15.497 ms 15.548 ms 4 mrfddsrj01gex070003.rd.dc.cox.net (68.100.0.141) 13.594 ms 13.765 ms 13.817 ms 5 68.1.4.139 (68.1.4.139) 14.752 ms 15.016 ms 14.951 ms 6 ge-8-0-7.er2.iad10.us.above.net (64.125.12.241) 15.075 ms 9.565 ms 9.384 ms 7 xe-5-1-0.cr2.dca2.us.above.net (64.125.29.77) 33.238 ms 26.629 ms 26.554 ms 8 xe-2-2-0.cr2.iah1.us.above.net (64.125.30.53) 45.079 ms 45.230 ms 45.264 ms 9 xe-0-3-0.cr2.lax112.us.above.net (64.125.30.50) 75.982 ms 76.212 ms 76.154 ms 10 xe-2-1-0.cr2.sjc2.us.above.net (64.125.26.30) 93.901 ms 94.044 ms 88.715 ms 11 xe-1-1-0.er2.sjc2.us.above.net (64.125.26.202) 88.542 ms 88.885 ms 90.094 ms 12 64.124.201.230.b709.above.net (64.124.201.230) 89.691 ms 89.060 ms 88.895 ms 13 * * * 14 * * * 15 * * * traceroute -T -p 80 216.200.241.66 traceroute to 216.200.241.66 (216.200.241.66), 30 hops max, 60 byte packets 1 sark.dirtside.com (70.182.189.216) 0.487 ms 0.520 ms 0.568 ms 2 10.1.192.1 (10.1.192.1) 20.018 ms 24.851 ms 25.144 ms 3 ip72-196-255-1.dc.dc.cox.net (72.196.255.1) 25.415 ms 25.502 ms 25.591 ms 4 mrfddsrj01gex070003.rd.dc.cox.net (68.100.0.141) 25.139 ms 25.178 ms 25.260 ms 5 68.1.4.139 (68.1.4.139) 37.509 ms 37.437 ms 37.362 ms 6 ge-5-3-0.mpr2.iad10.us.above.net (64.125.13.57) 91.097 ms 89.808 ms ge-8-0-7.er2.iad10.us.above.net (64.125.12.241) 24.078 ms 7 xe-5-1-0.cr2.dca2.us.above.net (64.125.29.77) 26.324 ms 11.950 ms 12.477 ms 8 xe-2-2-0.cr2.iah1.us.above.net (64.125.30.53) 74.680 ms 74.575 ms 74.355 ms 9 xe-0-3-0.cr2.lax112.us.above.net (64.125.30.50) 76.781 ms 76.330 ms 76.118 ms 10 xe-2-1-0.cr2.sjc2.us.above.net (64.125.26.30) 100.310 ms 100.026 ms 98.495 ms 11 xe-1-1-0.er2.sjc2.us.above.net (64.125.26.202) 98.631 ms 93.570 ms 94.380 ms 12 64.124.201.230.b709.above.net (64.124.201.230) 94.420 ms 97.053 ms 95.015 ms 13 208.185.174.208 (208.185.174.208) 96.208 ms 96.541 ms 96.384 ms 14 www.checkpoint.com (216.200.241.66) 97.406 ms 97.534 ms 97.891 ms Since you get all the way to the Checkpoint border, try some basic diagnostics like: telnet www.checkpoint.com 80 GET / HTTP/1.1 Host: www.checkpoint.com Wait for the telnet to succeed before you type GET. Make sure you press enter twice after the last line. You're hand-jamming an HTTP request. If you don't connect then checkpoint is blocking your IP address for one reason or another. Maybe there are hackers in your neighborhood. Take it up with them by phone. If you do connect but get no response to the "get" http request then most likely checkpoint is blocking all ICMP packets and your path MTU is smaller than 1500 bytes. The ICMP block prevents the fragmentation needed message from reaching their web server, so it never figures out it needs to shorten its packets. If, as a firewall company, they have made this beginner mistake... 'nuff said. And of course if you do get complete content back from the web server then you have some other problem with your PC that's getting in the way. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wmf at felter.org Tue Aug 7 12:50:48 2012 From: wmf at felter.org (Wes Felter) Date: Tue, 07 Aug 2012 12:50:48 -0500 Subject: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?) In-Reply-To: References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: On 8/6/12 8:04 PM, Owen DeLong wrote: > The goal here was to make this as simple and cost-effective as the NAT-based > IPv4 solution currently in common use. There's no reason it can't be exactly that. > > It does provide advantages over the NAT-based solution (sessions can survive > failover). What do people think about Fred Templin's IRON multihomed tunneling approach (or LISP, I guess it can do it)? IRON should give you multihoming with stable IPv4 and IPv6 PA prefixes, even for incoming traffic. It's less reliable than BGP in theory since you'd be virtually single-homed to your IRON provider but that might be a worthwhile tradeoff since staying up is pretty much their purpose in life. You'd have to pay a third provider to terminate your tunnels, but that might be cheaper than paying an extra BGP tax to both of your physical providers. IRON appears to require much less configuration than BGP and it can also provide IPv6 over v4-only providers (good luck finding *two* broadband providers in the same location that provide IPv6 and BGP). -- Wes Felter IBM Research - Austin From owen at delong.com Tue Aug 7 13:37:18 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Aug 2012 11:37:18 -0700 Subject: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?) In-Reply-To: References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: <9B3CFBE6-1606-4A41-8C1C-7B6E07A2C32D@delong.com> On Aug 7, 2012, at 10:50 , Wes Felter wrote: > On 8/6/12 8:04 PM, Owen DeLong wrote: > >> The goal here was to make this as simple and cost-effective as the NAT-based >> IPv4 solution currently in common use. There's no reason it can't be exactly that. >> >> It does provide advantages over the NAT-based solution (sessions can survive >> failover). > > What do people think about Fred Templin's IRON multihomed tunneling approach (or LISP, I guess it can do it)? IRON should give you multihoming with stable IPv4 and IPv6 PA prefixes, even for incoming traffic. It's less reliable than BGP in theory since you'd be virtually single-homed to your IRON provider but that might be a worthwhile tradeoff since staying up is pretty much their purpose in life. > > You'd have to pay a third provider to terminate your tunnels, but that might be cheaper than paying an extra BGP tax to both of your physical providers. IRON appears to require much less configuration than BGP and it can also provide IPv6 over v4-only providers (good luck finding *two* broadband providers in the same location that provide IPv6 and BGP). > > -- > Wes Felter > IBM Research - Austin > > > I think IRON has some promise as well and might be interesting in some scenarios. I think developing both is worth while. Different tools for different jobs. Owen From khelms at ispalliance.net Tue Aug 7 14:05:55 2012 From: khelms at ispalliance.net (Scott Helms) Date: Tue, 07 Aug 2012 15:05:55 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: <77DB70B8-CE7A-48F4-9393-E17C0005EE1F@delong.com> References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> <77DB70B8-CE7A-48F4-9393-E17C0005EE1F@delong.com> Message-ID: <50216713.1060006@ispalliance.net> The problem you're missing is that there is 0 market pressure to build and standardize all of this. Netconf isn't a claimed standard yet much less a functional one in the SOHO world. Lets assume for a moment that someone finds enough of a reason to herd the cats that are the soho router market and gets them to adopt Netconf or another rational method for distributed configuration, you haven't dealt with the hardest problem. The router configuration isn't the most challenging one. _What_ to communicate or configure is the hard part and unless you're going to put the service provider in charge of the BGP session very few businesses have the internal OR external resources to answer these simple questions. 1. The ASN number of the two providers //smb response, what's an ASN? Why do I have pay for one, I already pay for Internet service. 2. The ASN to be used for the local side //read response 1 3. The IP Address to use on the local end of each connection //who figures this out? 4. The IP Address to peer with on each connection //same question 5. The prefix(es) to be advertised. //again, who figures this out? On 8/6/2012 7:38 PM, Owen DeLong wrote: > On Aug 6, 2012, at 16:15 , William Herrin wrote: > >> On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong wrote: >>> That's simply not true at all... >>> >>> Let's look at what it takes to configure BGP as I suggested... >>> >>> 1. The ASN number of the two providers >>> 2. The ASN to be used for the local side >>> 3. The IP Address to use on the local end of each connection >>> 4. The IP Address to peer with on each connection >>> 5. The prefix(es) to be advertised. >> Add to that: >> >> 6. Primary A, Primary B, Balanced (routing priority via AS path prepends) > Not absolutely required and certainly going beyond what is required to provide slightly better than the functionality provided with the dual-NAT scenario. > >> 7. Optional password for each session (some ISPs require one) > Fair enough, but pretty trivial. > >> Or take another tack: have the SOHO router accept a URL for each BGP >> connection and have the provider build the config. Then all you enter >> is your provider-assigned interface address, a DNS server address and >> a URL. > Well, I was going for zeroconf, but yes, that was basically allowed for in what I described. > >> Your point is well taken. A leaf node BGP configuration could be >> simplified to the point where it fits on a SOHO router config page and >> does not require an expert to configure. >> > Yep... And it could even be made 100% automated zeroconf with a little more effort. > > It could even use provider-assigned private-ASNs and a shared PA prefix with a little additional ingenuity. > > Owen > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From valdis.kletnieks at vt.edu Tue Aug 7 14:51:03 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 07 Aug 2012 15:51:03 -0400 Subject: BGPttH. Neustar can do it, why can't we? In-Reply-To: Your message of "Mon, 06 Aug 2012 15:55:19 -0700." <12289110-9310-474C-8457-0E2C25562565@delong.com> References: <40712D04-C184-4DE9-A7D0-D8917AD8D4E3@delong.com> <50202622.8010706@ispalliance.net> <50203FA1.8050503@ispalliance.net> <12289110-9310-474C-8457-0E2C25562565@delong.com> Message-ID: <52997.1344369063@turing-police.cc.vt.edu> On Mon, 06 Aug 2012 15:55:19 -0700, Owen DeLong said: > That would allow a zeroconf BGP-enabled router in relatively small hardware accepting a default route t OK Owen, I'll bite - what are the chances that a zeroconf router will accept the *wrong* default route? If you're trying to do the "Use this provider unless it dies, then use the other link", you can't really do that as zero-conf, you'll need to tell it which side is A and which is B. And if you're trying to do routing across both links at once, that's even worse for zeroconf. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From David.Wilde at aarnet.edu.au Tue Aug 7 18:59:58 2012 From: David.Wilde at aarnet.edu.au (David Wilde) Date: Tue, 7 Aug 2012 23:59:58 +0000 Subject: Wanted: Asia bandwidth test files In-Reply-To: <87r4ri92jz.fsf@minnow.riseup.net> References: <87zk6d899k.fsf@minnow.riseup.net> <3AFB87B02BA2FE42B4EDEC3CDAFE58821B729782@SYD-VM-MBX1.ms.aarnet.edu.au> <87r4ri92jz.fsf@minnow.riseup.net> Message-ID: <3AFB87B02BA2FE42B4EDEC3CDAFE58821B72A5B7@SYD-VM-MBX1.ms.aarnet.edu.au> Hi Micah, > From: micah anderson [mailto:micah at riseup.net] > > Thanks for the suggestion. Do you know what their bandwidth is? I can > easily pull a .iso or similar from there to do some tests. > There's some info at http://mirror.aarnet.edu.au/indexabout.html - it's connected at 10Gbps. Naturally what throughput you're able to get will depend on how you arrive on the AARNet network - there is unfortunately less bandwidth into the west of Australia from Asia is than there is into the east coast from the United States. David From tvhawaii at shaka.com Tue Aug 7 22:15:51 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 7 Aug 2012 17:15:51 -1000 Subject: raging bulls References: <20120807122509.GC12615@leitl.org> Message-ID: <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> Eugen Leitl wrote: > http://www.wired.com/business/2012/08/ff_wallstreet_trading/all/ > > Some interesting, network-relevant content there (but for the > neutrino and drone rubbish). 'Rubbish' might be a pretty strong word when you're talking about the players in this space. My favorite from the article: "But perhaps not even Einstein fully appreciated the degree to which electromagnetic waves bend in the presence of money. " From eugen at leitl.org Wed Aug 8 02:02:07 2012 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 8 Aug 2012 09:02:07 +0200 Subject: raging bulls In-Reply-To: <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> Message-ID: <20120808070207.GN12615@leitl.org> On Tue, Aug 07, 2012 at 05:15:51PM -1000, Michael Painter wrote: > Eugen Leitl wrote: >> http://www.wired.com/business/2012/08/ff_wallstreet_trading/all/ >> >> Some interesting, network-relevant content there (but for the >> neutrino and drone rubbish). > > 'Rubbish' might be a pretty strong word when you're talking about the players in this space. If you want to shave off ms, using a source that takes at least minutes to accrue enough signal for a single bit is definitely not what you want. And drones across the Atlantic is way too Rube Goldbergesque to contemplate. > My favorite from the article: > "But perhaps not even Einstein fully appreciated the degree to which > electromagnetic waves bend in the presence of money. " Maybe they should invest into a dense, a really low LEO sat constellation, and go by way of LoS laser. From eugen at imacandi.net Wed Aug 8 04:06:32 2012 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 8 Aug 2012 12:06:32 +0300 Subject: next hop packet loss In-Reply-To: <530DFF0280267643A67908BB181189E5981DE9@garcia.neuse.local> References: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> <50203C33.9040506@ninjabadger.net> <5be2f848f21f8348447f2e4fc9738420.squirrel@g.mail.aa.net.uk> <530DFF0280267643A67908BB181189E5981DE9@garcia.neuse.local> Message-ID: On Tue, Aug 7, 2012 at 4:12 PM, Jim Ray wrote: > Sorry, I do not give verbose responses via iPhone on that small device > with my tired old eyes. I ran Wireshark this morning. > > Without sniffing packets, the layman's description of problem is "I > can't get to vendor web site, http://www.CheckPoint.com, on Time Warner > Business Class network I use." Hence, http is blocked in addition to > ICMP. > Yesterday, Check Point's website was unreachable from other parts of the world for some time with intermittent access for around an hour or so I believe. Eugeniu From olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Wed Aug 8 02:37:26 2012 From: olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa (Oliver) Date: Wed, 08 Aug 2012 09:37:26 +0200 Subject: Trouble with IPv6 setup on Quagga In-Reply-To: References: Message-ID: <1876003.nJFbuIMgX6@gentoovm> On Tuesday 07 August 2012 01:08:24 Anurag Bhatia wrote: > > router bgp 54456 > bgp router-id 199.116.78.28 > redistribute connected metric 1 > redistribute static metric 1 > neighbor 2607:1b00:10:a::1 remote-as 54456 > neighbor 2607:1b00:10:a::1 next-hop-self > > address-family ipv6 > network 2607:1b00:d1::/48 > network 2607:1b00:d2::/48 > neighbor 2607:1b00:10:a::1 activate > exit-address-family Specifying "next-hop-self" in the general BGP router config section is equivalent to specifying it purely for IPv4 routes; you need to specify next- hop-self in the IPv6 address-family section. Regards, Oliver From nanog at stefan-neufeind.de Wed Aug 8 06:29:18 2012 From: nanog at stefan-neufeind.de (Stefan Neufeind) Date: Wed, 08 Aug 2012 13:29:18 +0200 Subject: Trouble with IPv6 setup on Quagga In-Reply-To: <1876003.nJFbuIMgX6@gentoovm> References: <1876003.nJFbuIMgX6@gentoovm> Message-ID: <50224D8E.8010907@stefan-neufeind.de> On 08/08/2012 09:37 AM, Oliver wrote: > On Tuesday 07 August 2012 01:08:24 Anurag Bhatia wrote: >> >> router bgp 54456 >> bgp router-id 199.116.78.28 >> redistribute connected metric 1 >> redistribute static metric 1 >> neighbor 2607:1b00:10:a::1 remote-as 54456 >> neighbor 2607:1b00:10:a::1 next-hop-self >> >> address-family ipv6 >> network 2607:1b00:d1::/48 >> network 2607:1b00:d2::/48 >> neighbor 2607:1b00:10:a::1 activate >> exit-address-family > > Specifying "next-hop-self" in the general BGP router config section is > equivalent to specifying it purely for IPv4 routes; you need to specify next- > hop-self in the IPv6 address-family section. And you might want to disable ("no neighbor ... activate") for the default-protocol (IPv4) as otherwise Quagga tries to advertise IPv4 over the same session as well - which you usually wouldn't want to. I've seen cases where both sides ran Quagga and wondered where all the (unfiltered) IPv4-routes came from :-) Regards, Stefan From SNaslund at medline.com Wed Aug 8 08:52:51 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 08:52:51 -0500 Subject: raging bulls In-Reply-To: <20120808070207.GN12615@leitl.org> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> It seems to me that all the markets have been doing this the wrong way. Would it now be more fair to use some kind of signed timestamp and process all transactions in the order that they originated? Perhaps each trade could have a signed GPS tag with the absolute time on it. It would keep everyone's trades in order no matter how latent their connection to the market was. All you would have to do is introduce a couple of seconds delay to account for the longest circuit and then take them in order. They could certainly use less expensive connections and ensure that international traders get a fair shake. Steven Naslund -----Original Message----- From: Eugen Leitl [mailto:eugen at leitl.org] Sent: Wednesday, August 08, 2012 2:02 AM To: nanog at nanog.org Subject: Re: raging bulls On Tue, Aug 07, 2012 at 05:15:51PM -1000, Michael Painter wrote: > Eugen Leitl wrote: >> http://www.wired.com/business/2012/08/ff_wallstreet_trading/all/ >> >> Some interesting, network-relevant content there (but for the >> neutrino and drone rubbish). > > 'Rubbish' might be a pretty strong word when you're talking about the players in this space. If you want to shave off ms, using a source that takes at least minutes to accrue enough signal for a single bit is definitely not what you want. And drones across the Atlantic is way too Rube Goldbergesque to contemplate. > My favorite from the article: > "But perhaps not even Einstein fully appreciated the degree to which > electromagnetic waves bend in the presence of money. " Maybe they should invest into a dense, a really low LEO sat constellation, and go by way of LoS laser. From SNaslund at medline.com Wed Aug 8 09:04:18 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 09:04:18 -0500 Subject: raging bulls In-Reply-To: References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16552@MUNEXBE1.medline.com> There should be some sorts of way to authenticate a GPS timestamp. GPS may not be able to do it today but a satellite network could in theory cryptographically sign a time stamp so that is can only be decrypted by the receiver at the market data center. Either that or some kind of ground based hardware device that syncs with a satellite and generates a key stream so that the receiver can tell when something happened by where the device is in the stream. I am thinking of something along the lines of SecureID where the keys change every so often, I would just have to be lots faster. Steve -----Original Message----- From: Chu, Yi [NTK] [mailto:Yi.Chu at sprint.com] Sent: Wednesday, August 08, 2012 9:01 AM To: Naslund, Steve; nanog at nanog.org Subject: RE: raging bulls What prevents someone to fake an earlier timestamp? Money can bend light, sure can a few msec. yi -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Wednesday, August 08, 2012 9:53 AM To: nanog at nanog.org Subject: RE: raging bulls It seems to me that all the markets have been doing this the wrong way. Would it now be more fair to use some kind of signed timestamp and process all transactions in the order that they originated? Perhaps each trade could have a signed GPS tag with the absolute time on it. It would keep everyone's trades in order no matter how latent their connection to the market was. All you would have to do is introduce a couple of seconds delay to account for the longest circuit and then take them in order. They could certainly use less expensive connections and ensure that international traders get a fair shake. Steven Naslund -----Original Message----- From: Eugen Leitl [mailto:eugen at leitl.org] Sent: Wednesday, August 08, 2012 2:02 AM To: nanog at nanog.org Subject: Re: raging bulls On Tue, Aug 07, 2012 at 05:15:51PM -1000, Michael Painter wrote: > Eugen Leitl wrote: >> http://www.wired.com/business/2012/08/ff_wallstreet_trading/all/ >> >> Some interesting, network-relevant content there (but for the >> neutrino and drone rubbish). > > 'Rubbish' might be a pretty strong word when you're talking about the players in this space. If you want to shave off ms, using a source that takes at least minutes to accrue enough signal for a single bit is definitely not what you want. And drones across the Atlantic is way too Rube Goldbergesque to contemplate. > My favorite from the article: > "But perhaps not even Einstein fully appreciated the degree to which > electromagnetic waves bend in the presence of money. " Maybe they should invest into a dense, a really low LEO sat constellation, and go by way of LoS laser. ________________________________ This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From SNaslund at medline.com Wed Aug 8 09:08:18 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 09:08:18 -0500 Subject: raging bulls In-Reply-To: References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16560@MUNEXBE1.medline.com> Also, we are only talking about a delay long enough to satisfy the longest circuit so you could not push your timestamp very far back and would have to get the fake one done pretty quickly in order for it to be worthwhile. The real question is could you fake a cryptographic timestamp fast enough to actually gain time on the system. Possibly but it would be a very tall order. Steve -----Original Message----- From: Chu, Yi [NTK] [mailto:Yi.Chu at sprint.com] Sent: Wednesday, August 08, 2012 9:01 AM To: Naslund, Steve; nanog at nanog.org Subject: RE: raging bulls What prevents someone to fake an earlier timestamp? Money can bend light, sure can a few msec. yi -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Wednesday, August 08, 2012 9:53 AM To: nanog at nanog.org Subject: RE: raging bulls It seems to me that all the markets have been doing this the wrong way. Would it now be more fair to use some kind of signed timestamp and process all transactions in the order that they originated? Perhaps each trade could have a signed GPS tag with the absolute time on it. It would keep everyone's trades in order no matter how latent their connection to the market was. All you would have to do is introduce a couple of seconds delay to account for the longest circuit and then take them in order. They could certainly use less expensive connections and ensure that international traders get a fair shake. Steven Naslund From rbf+nanog at panix.com Wed Aug 8 09:08:27 2012 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 8 Aug 2012 09:08:27 -0500 Subject: raging bulls In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> Message-ID: <20120808140827.GA11596@panix.com> On Wed, Aug 08, 2012 at 08:52:51AM -0500, Naslund, Steve wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. It > would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then take > them in order. They could certainly use less expensive connections and > ensure that international traders get a fair shake. This isn't about giving international traders a fair shake. This sort of latency is only relevant to high speed program trading, and the international traders can locate their servers in NYC just as easily as the US-based traders. What it's about is allowing traders to arbitrage between markets. When product A is traded in, say, London, and product B is traded in New York, and their prices are correlated, you can make money if your program running in NY can learn the price of product B in London a few milliseconds before the other guy's program. And you can make money if your program running in London can learn the price of product A in NY a few milliseconds before the other guy's program. Even if you execute the trades based on a GPS timestamp (I'm ignoring all the logistics of preventing cheating here), it doesn't matter, because the computer that got the information first will make the trading decision first. -- Brett From SNaslund at medline.com Wed Aug 8 09:14:13 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 09:14:13 -0500 Subject: raging bulls In-Reply-To: <20120808140827.GA11596@panix.com> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> <20120808140827.GA11596@panix.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16574@MUNEXBE1.medline.com> It is a tough technical problem to be sure but not insurmountable. Think about a system in which the real time market data is also encrypted in such a way that it can only be decrypted at a particular point in time. Essentially it would be like each trading system receiving an envelope that must be opened simultaneously. Picture a satellite network that is time synchronized to transmit a key stream used to decrypt the data that is received over a terrestrial network. I am not talking about easy to implement here just what is possible. It is probably easier than faster than light travel although I supposed real estate on Mt Everest could get very valuable (closer to the satellites) :) Steve -----Original Message----- From: Brett Frankenberger [mailto:rbf+nanog at panix.com] Sent: Wednesday, August 08, 2012 9:08 AM To: Naslund, Steve Cc: nanog at nanog.org Subject: Re: raging bulls On Wed, Aug 08, 2012 at 08:52:51AM -0500, Naslund, Steve wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. > It would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then > take them in order. They could certainly use less expensive > connections and ensure that international traders get a fair shake. This isn't about giving international traders a fair shake. This sort of latency is only relevant to high speed program trading, and the international traders can locate their servers in NYC just as easily as the US-based traders. What it's about is allowing traders to arbitrage between markets. When product A is traded in, say, London, and product B is traded in New York, and their prices are correlated, you can make money if your program running in NY can learn the price of product B in London a few milliseconds before the other guy's program. And you can make money if your program running in London can learn the price of product A in NY a few milliseconds before the other guy's program. Even if you execute the trades based on a GPS timestamp (I'm ignoring all the logistics of preventing cheating here), it doesn't matter, because the computer that got the information first will make the trading decision first. -- Brett From rbf+nanog at panix.com Wed Aug 8 09:16:56 2012 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 8 Aug 2012 09:16:56 -0500 Subject: raging bulls In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16560@MUNEXBE1.medline.com> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> <2A76E400AC84B845AAC35AA19F8E7A5D0BC16560@MUNEXBE1.medline.com> Message-ID: <20120808141656.GB11596@panix.com> On Wed, Aug 08, 2012 at 09:08:18AM -0500, Naslund, Steve wrote: > Also, we are only talking about a delay long enough to satisfy the > longest circuit so you could not push your timestamp very far back and > would have to get the fake one done pretty quickly in order for it to be > worthwhile. The real question is could you fake a cryptographic > timestamp fast enough to actually gain time on the system. Possibly but > it would be a very tall order. Why would generating a fake timestamp take longer than generating a real one? I assume you're proposing an architecture where if I were a trader, I'd have to buy a secure physical box from a third party trusted by the market, and I'd send my trade to that box and then it would timestamp it and sign it and then I'd send it to the market. Obvious failure modes include: (a) spoofing the GPS signal received by the box, so the box thinks the current time is some number of milliseconds before the actual time (how to do this is well understood and solved, and because GPS is one-way, even if the satellites started signing their time updates, that would only prevent spoofing times in the future, it wouldn't prevent spoofing times on the past), and (b) generating 10 trades at time X, then holding on to the signed messages until X+Y, and then only sending the ones that are profitable based on the new information you learned between (X) and (X+Y). Yes, there are some solutions. But most of those solutions have problems of their own. It's overwhelmingly difficult. (But also irrelevant, as I noted in my other post). If you think this through to what a working implementation would look like in detail, I think the failures become more obvious ... -- Brett From malayter at gmail.com Wed Aug 8 09:20:23 2012 From: malayter at gmail.com (Ryan Malayter) Date: Wed, 8 Aug 2012 09:20:23 -0500 Subject: raging bulls Message-ID: "Naslund, Steve" wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. It > would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then take > them in order. They could certainly use less expensive connections and > ensure that international traders get a fair shake. I can't see any incentive for any *influential* party involved (the big firms or the exchanges) to make the process "fair". The exchange gets more money for low-latency network access and expensive co-location. The moneyed firms with HFT capability of course do not want anyone else to have their advantage. Even governments don't want long-distance traders to have "fair" access, as that reduces the advantage of local tax-paying firms, thereby reducing tax revenue, jobs, etc. HFT is not just a US phenomenon; all major exchanges have basically the same sort of phenomenon. So UK-based trading firms with HFT setups very close to the FTSE exchanges have advantage over US-based firms that don't have HFT setups in London. -- RPM From joelja at bogus.com Wed Aug 8 09:23:20 2012 From: joelja at bogus.com (joel jaeggli) Date: Wed, 08 Aug 2012 07:23:20 -0700 Subject: raging bulls In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> Message-ID: <50227658.3070108@bogus.com> On 8/8/12 6:52 AM, Naslund, Steve wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Given an uneven distribution of sizes it's kind of hard to fill orders in the order in which they arrived (unmatched orders are part of a normally functioning market). A large bid may require the accumulation of sell orders while smaller orders may be more easily matched. Some HF trading strategies of course rely on this. Today large orders may be filled on more than one ecn at a time so the notion of central agency in clearance is also a little challenging. > Perhaps > each trade could have a signed GPS tag with the absolute time on it. It > would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then take > them in order. They could certainly use less expensive connections and > ensure that international traders get a fair shake. it's simpler to just locate the trading platforms in the same place and give everyone the same length cable. The incentives are in the wrong place too deliberately induce delay without some externality (like a regulator) guiding behavior. If one sees current behavior as undesirable there are other methods such as the adjustment of transaction costs that might be more effective. From SNaslund at medline.com Wed Aug 8 09:22:46 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 09:22:46 -0500 Subject: raging bulls In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16560@MUNEXBE1.medline.com> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> <2A76E400AC84B845AAC35AA19F8E7A5D0BC16560@MUNEXBE1.medline.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16593@MUNEXBE1.medline.com> Here is another thought. Many people think that the rapid computer trading does not really add any value to the market in any case since there is no long term investment. That point is debatable but if you really believed that, you could end all of that by adding a randomized delay to data transmission and processing of transactions to make the entire debate pointless and ensure that no one has any consistent advantage at all. Steve -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Wednesday, August 08, 2012 9:08 AM To: nanog at nanog.org Subject: RE: raging bulls Also, we are only talking about a delay long enough to satisfy the longest circuit so you could not push your timestamp very far back and would have to get the fake one done pretty quickly in order for it to be worthwhile. The real question is could you fake a cryptographic timestamp fast enough to actually gain time on the system. Possibly but it would be a very tall order. Steve -----Original Message----- From: Chu, Yi [NTK] [mailto:Yi.Chu at sprint.com] Sent: Wednesday, August 08, 2012 9:01 AM To: Naslund, Steve; nanog at nanog.org Subject: RE: raging bulls What prevents someone to fake an earlier timestamp? Money can bend light, sure can a few msec. yi -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Wednesday, August 08, 2012 9:53 AM To: nanog at nanog.org Subject: RE: raging bulls It seems to me that all the markets have been doing this the wrong way. Would it now be more fair to use some kind of signed timestamp and process all transactions in the order that they originated? Perhaps each trade could have a signed GPS tag with the absolute time on it. It would keep everyone's trades in order no matter how latent their connection to the market was. All you would have to do is introduce a couple of seconds delay to account for the longest circuit and then take them in order. They could certainly use less expensive connections and ensure that international traders get a fair shake. Steven Naslund From mloftis at wgops.com Wed Aug 8 09:56:23 2012 From: mloftis at wgops.com (Michael Loftis) Date: Wed, 8 Aug 2012 08:56:23 -0600 Subject: raging bulls In-Reply-To: <20120808140827.GA11596@panix.com> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> <20120808140827.GA11596@panix.com> Message-ID: On Wed, Aug 8, 2012 at 8:08 AM, Brett Frankenberger wrote: > Even if you execute the trades based on a GPS timestamp (I'm ignoring > all the logistics of preventing cheating here), it doesn't matter, > because the computer that got the information first will make the > trading decision first. > > -- Brett > Such a system would be pretty complicated because it would also have to prevent intentional 'backdating' of trades as well. Then you've got the market data itself (as just mentioned) -- getting the information first is a big part of the latency problem for the quants. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From adam.vitkovsky at swan.sk Wed Aug 8 10:02:13 2012 From: adam.vitkovsky at swan.sk (adam vitkovsky) Date: Wed, 8 Aug 2012 17:02:13 +0200 Subject: raging bulls In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16574@MUNEXBE1.medline.com> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> <20120808140827.GA11596@panix.com> <2A76E400AC84B845AAC35AA19F8E7A5D0BC16574@MUNEXBE1.medline.com> Message-ID: <01b601cd7576$cacff730$606fe590$@swan.sk> No, not ever shorter under-see cables no. NEUTRINOS -shooting information at speed of light right through the earth (not around it) Should there be any high speed traders in here this is what you should invest all your money in to gain advantage against your competition First it was cold war times which gave birth to the Internet, that has changed our lives from the ground up Maybe this time it will be the stock markets and scent of money that will give the communication development spiral an unimaginable momentum adam -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Wednesday, August 08, 2012 4:14 PM To: nanog at nanog.org Subject: RE: raging bulls It is a tough technical problem to be sure but not insurmountable. Think about a system in which the real time market data is also encrypted in such a way that it can only be decrypted at a particular point in time. Essentially it would be like each trading system receiving an envelope that must be opened simultaneously. Picture a satellite network that is time synchronized to transmit a key stream used to decrypt the data that is received over a terrestrial network. I am not talking about easy to implement here just what is possible. It is probably easier than faster than light travel although I supposed real estate on Mt Everest could get very valuable (closer to the satellites) :) Steve -----Original Message----- From: Brett Frankenberger [mailto:rbf+nanog at panix.com] Sent: Wednesday, August 08, 2012 9:08 AM To: Naslund, Steve Cc: nanog at nanog.org Subject: Re: raging bulls On Wed, Aug 08, 2012 at 08:52:51AM -0500, Naslund, Steve wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. > It would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then > take them in order. They could certainly use less expensive > connections and ensure that international traders get a fair shake. This isn't about giving international traders a fair shake. This sort of latency is only relevant to high speed program trading, and the international traders can locate their servers in NYC just as easily as the US-based traders. What it's about is allowing traders to arbitrage between markets. When product A is traded in, say, London, and product B is traded in New York, and their prices are correlated, you can make money if your program running in NY can learn the price of product B in London a few milliseconds before the other guy's program. And you can make money if your program running in London can learn the price of product A in NY a few milliseconds before the other guy's program. Even if you execute the trades based on a GPS timestamp (I'm ignoring all the logistics of preventing cheating here), it doesn't matter, because the computer that got the information first will make the trading decision first. -- Brett From SNaslund at medline.com Wed Aug 8 10:16:01 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 10:16:01 -0500 Subject: raging bulls In-Reply-To: <20120808144544.GA93761@snar.spb.ru> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> <2A76E400AC84B845AAC35AA19F8E7A5D0BC16560@MUNEXBE1.medline.com> <20120808144544.GA93761@snar.spb.ru> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16647@MUNEXBE1.medline.com> Are there not mechanisms to handle replay attacks? There is also the minor matter of fraud and regulatory concerns. You might get away with it a few times but not often enough to avoid a potential death penalty of being disconnected. Steve -----Original Message----- From: Alexandre Snarskii [mailto:snar at snar.spb.ru] Sent: Wednesday, August 08, 2012 9:46 AM To: Naslund, Steve Cc: Alexandre Snarskii Subject: Re: raging bulls On Wed, Aug 08, 2012 at 09:08:18AM -0500, Naslund, Steve wrote: > Also, we are only talking about a delay long enough to satisfy the > longest circuit so you could not push your timestamp very far back and > would have to get the fake one done pretty quickly in order for it to > be worthwhile. The real question is could you fake a cryptographic > timestamp fast enough to actually gain time on the system. Possibly > but it would be a very tall order. Looks like replay attack works here: "attacker" can easily record encrypted timestamps and reuse them some milliseconds later, claiming "I had no knowledge on how market changed during this time, it's my provider had to re-route my traffic!!" > > Steve > > -----Original Message----- > From: Chu, Yi [NTK] [mailto:Yi.Chu at sprint.com] > Sent: Wednesday, August 08, 2012 9:01 AM > To: Naslund, Steve; nanog at nanog.org > Subject: RE: raging bulls > > What prevents someone to fake an earlier timestamp? Money can bend > light, sure can a few msec. > > yi > > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund at medline.com] > Sent: Wednesday, August 08, 2012 9:53 AM > To: nanog at nanog.org > Subject: RE: raging bulls > > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. > It would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then > take them in order. They could certainly use less expensive > connections and ensure that international traders get a fair shake. > > Steven Naslund > > -- In theory, there is no difference between theory and practice. But, in practice, there is. From SNaslund at medline.com Wed Aug 8 10:24:21 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 10:24:21 -0500 Subject: raging bulls In-Reply-To: <50227658.3070108@bogus.com> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> <50227658.3070108@bogus.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC1665F@MUNEXBE1.medline.com> This is a bit like an arms race. The markets will most likely have to level their own playing field. That is up to them. The markets may like high frequency trading but if more and more traders become disadvantaged they will act to level things out. They also would not like the government to step in which they are always apt to do. The government in general I think seems highly negative on high frequency trading because there is some systemic risk in systems handling large amounts of transactions at such a high rate. We have seen tremendous errors in the past and we are almost reaching the point where a firm will not be able to survive a system error or could cause a cascade effect. The question the markets and regulators always have to ask themselves is whether the market is fundamentally fair. The government has the additional duty of determining whether a market activity is detrimental to the economy of the nation involved. It is not for me to answer the question of whether this should be implemented, I am just saying that it is technically feasible to do so. As far as locating all the servers in the same place on the same length of cable, that apparently is not in the cards or you would not see the high cost specialized networks from Chicago to NYC. Steve -----Original Message----- From: joel jaeggli [mailto:joelja at bogus.com] Sent: Wednesday, August 08, 2012 9:23 AM To: Naslund, Steve Cc: nanog at nanog.org Subject: Re: raging bulls On 8/8/12 6:52 AM, Naslund, Steve wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Given an uneven distribution of sizes it's kind of hard to fill orders in the order in which they arrived (unmatched orders are part of a normally functioning market). A large bid may require the accumulation of sell orders while smaller orders may be more easily matched. Some HF trading strategies of course rely on this. Today large orders may be filled on more than one ecn at a time so the notion of central agency in clearance is also a little challenging. > Perhaps > each trade could have a signed GPS tag with the absolute time on it. > It would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then > take them in order. They could certainly use less expensive > connections and ensure that international traders get a fair shake. it's simpler to just locate the trading platforms in the same place and give everyone the same length cable. The incentives are in the wrong place too deliberately induce delay without some externality (like a regulator) guiding behavior. If one sees current behavior as undesirable there are other methods such as the adjustment of transaction costs that might be more effective. From SNaslund at medline.com Wed Aug 8 10:34:52 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 10:34:52 -0500 Subject: raging bulls In-Reply-To: References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> <20120808140827.GA11596@panix.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC1667F@MUNEXBE1.medline.com> It might be complicated. I am just saying it is probably not as complicated as a permanent transatlantic aerial drone network or owning your own particle accelerator. I think all the anti-replay, anti-backdating concerns have probably been solved in the various public/private key networks, if not, there are certainly ways to do so. My only point was to say that there are technical ways to make high freq trading more inherently fair and there does not need to be a connectivity "arms race" unless that is what the markets want to do. The markets created this monster, they can't really complain about something they have the power to eliminate any time they want. If the majority of traders feel they are getting screwed, the policies will change. Looking at this from a strictly engineer's point of view, it seems like a very, very, risky way to handle extremely large sums of money. The systems are already outpacing the speeds they can be controlled and managed. At some point the systemic risk to the entire system will be the regulating factor. Let's hope they can head it off before it happens. I can very well see a point where a major system meltdown will cause an entire day of trading to be unwound because there is no other choice. You could always require all the trading systems to be in a single place but there will always be backend systems to control and monitor them somewhere else. Hey, putting everyone in the same place is how markets worked before when you needed a guy standing on the floor in order to operate. Steve -----Original Message----- From: Michael Loftis [mailto:mloftis at wgops.com] Sent: Wednesday, August 08, 2012 9:56 AM To: nanog at nanog.org Subject: Re: raging bulls On Wed, Aug 8, 2012 at 8:08 AM, Brett Frankenberger wrote: > Even if you execute the trades based on a GPS timestamp (I'm ignoring > all the logistics of preventing cheating here), it doesn't matter, > because the computer that got the information first will make the > trading decision first. > > -- Brett > Such a system would be pretty complicated because it would also have to prevent intentional 'backdating' of trades as well. Then you've got the market data itself (as just mentioned) -- getting the information first is a big part of the latency problem for the quants. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From johnl at iecc.com Wed Aug 8 10:54:14 2012 From: johnl at iecc.com (John Levine) Date: 8 Aug 2012 15:54:14 -0000 Subject: raging bulls In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16593@MUNEXBE1.medline.com> Message-ID: <20120808155414.39183.qmail@joyce.lan> >Here is another thought. Many people think that the rapid computer >trading does not really add any value to the market in any case since >there is no long term investment. It clearly doesn't. A proposal that's been kicking around for a while is to clear all trades once a second, so everyone has plenty of time to get them in no matter where they are. This has no chance of going anywhere, of course, until there's enough software disasters to provide political pushback against the leeches doing high speed trading. There is a new data center in Keflavik, Iceland. They advertise all of its fabulous green characteristics, e.g., power is from geothermal, and A/C is by opening the window, but it also happens to be closer to New York than anywhere in Europe, and closer to London than anywhere in North America, with good cable connections to both. R's, John From SNaslund at medline.com Wed Aug 8 11:10:41 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 11:10:41 -0500 Subject: raging bulls In-Reply-To: <20120808155414.39183.qmail@joyce.lan> References: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16593@MUNEXBE1.medline.com> <20120808155414.39183.qmail@joyce.lan> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC166F0@MUNEXBE1.medline.com> Just leaving room for disagreement on the value of HFT. It would seem to add nothing but more volatility to the market and make small events more extreme. There are also big risks of systems making convention wisdom decisions in unconventional situations. Can someone pull the plug fast enough if some unpredicted event makes the conventional wisdom wrong? The article in question uses an example like "oil price goes up, airline stocks go down". This sounds true enough but how many assumptions like this exist that might not ALWAYS be true. Is it fair to crater the airline industry or any other one because some convention like that causes a huge fast momentum swing. I guess the danger is that all the assumptions are those of a human but done at the speed of computing without natures built in safety catch of time to reconsider the assumption before pulling the trigger. We worry greatly over the software that controls aircraft and nuclear power plants but this software has a much greater potential for worldwide disaster and being a competitive market is probably changed many, many times more often in a less controlled way. You have to decide whether a global market meltdown and an aircraft crash can be compared but both are bad events. Again, this is a risk / reward situation that the markets and regulators need to deal with. I am normally not a big advocate for government control of anything but clearly there is a need for regulating an industry that has again and again done some very risky things that have very tangible effects on the world economy. When the speed limit of light becomes a major worry for your system, it peaks my radar as being a system that is running "on the edge". We are getting a bit off the NANOG subject which would be the network implications of this so I will curtail the general discussing of HFT. Steve -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Wednesday, August 08, 2012 10:54 AM To: nanog at nanog.org Cc: Naslund, Steve Subject: Re: raging bulls >Here is another thought. Many people think that the rapid computer >trading does not really add any value to the market in any case since >there is no long term investment. It clearly doesn't. A proposal that's been kicking around for a while is to clear all trades once a second, so everyone has plenty of time to get them in no matter where they are. This has no chance of going anywhere, of course, until there's enough software disasters to provide political pushback against the leeches doing high speed trading. There is a new data center in Keflavik, Iceland. They advertise all of its fabulous green characteristics, e.g., power is from geothermal, and A/C is by opening the window, but it also happens to be closer to New York than anywhere in Europe, and closer to London than anywhere in North America, with good cable connections to both. R's, John From detoler at gmail.com Wed Aug 8 11:34:23 2012 From: detoler at gmail.com (Duane Toler) Date: Wed, 8 Aug 2012 12:34:23 -0400 Subject: MXLogic outage Message-ID: Probably old news by now, but MXLogic folks are having some major issues today and not reliably receiving inbound mail. Several of our customers are talking with MXLogic about it. FYI. -- Duane Toler detoler at gmail.com From asullivan at dyn.com Wed Aug 8 11:37:32 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 8 Aug 2012 12:37:32 -0400 Subject: the topic (was: raging bulls) In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0BC166F0@MUNEXBE1.medline.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16593@MUNEXBE1.medline.com> <20120808155414.39183.qmail@joyce.lan> <2A76E400AC84B845AAC35AA19F8E7A5D0BC166F0@MUNEXBE1.medline.com> Message-ID: <20120808163732.GA22220@dyn.com> On Wed, Aug 08, 2012 at 11:10:41AM -0500, Naslund, Steve wrote: > We are getting a bit off the NANOG subject You think? A From blake at pfankuch.me Wed Aug 8 11:39:04 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Wed, 8 Aug 2012 16:39:04 +0000 Subject: MXLogic outage In-Reply-To: References: Message-ID: We are the same way. Phones going nuts ringing as we are an MXLogic partner. I am slowly getting email with about a 2-3 hour delay right now. Anyone know any more? -----Original Message----- From: Duane Toler [mailto:detoler at gmail.com] Sent: Wednesday, August 08, 2012 10:34 AM To: nanog at nanog.org Subject: MXLogic outage Probably old news by now, but MXLogic folks are having some major issues today and not reliably receiving inbound mail. Several of our customers are talking with MXLogic about it. FYI. -- Duane Toler detoler at gmail.com From rvandolson at esri.com Wed Aug 8 11:43:03 2012 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 8 Aug 2012 09:43:03 -0700 Subject: MXLogic outage In-Reply-To: References: Message-ID: <20120808164303.GA6358@esri.com> On Wed, Aug 08, 2012 at 04:39:04PM +0000, Blake Pfankuch wrote: > We are the same way. Phones going nuts ringing as we are an MXLogic > partner. I am slowly getting email with about a 2-3 hour delay right > now. Anyone know any more? > > -----Original Message----- > From: Duane Toler [mailto:detoler at gmail.com] > Sent: Wednesday, August 08, 2012 10:34 AM > To: nanog at nanog.org > Subject: MXLogic outage > > Probably old news by now, but MXLogic folks are having some major > issues today and not reliably receiving inbound mail. Several of our > customers are talking with MXLogic about it. > > FYI. What MX servers are your affected domains using? Ours are: 208.65.145.3 208.65.145.2 208.65.144.2 208.65.144.3 And no obvious delays currently. Ray From SNaslund at medline.com Wed Aug 8 11:41:14 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 8 Aug 2012 11:41:14 -0500 Subject: the topic (was: raging bulls) In-Reply-To: <20120808163732.GA22220@dyn.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16593@MUNEXBE1.medline.com> <20120808155414.39183.qmail@joyce.lan> <2A76E400AC84B845AAC35AA19F8E7A5D0BC166F0@MUNEXBE1.medline.com> <20120808163732.GA22220@dyn.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0BC16720@MUNEXBE1.medline.com> Thanks for such an intelligent comment that really adds to the discussion. For the record, 1. An article was posted talking about high speed network options. 2. I discussed why they might not be necessary 3. Various comments talked about high speed trading 4. I ended a subject that obviously veered off of networking So yeah "I think" to answer your question. Steve -----Original Message----- From: Andrew Sullivan [mailto:asullivan at dyn.com] Sent: Wednesday, August 08, 2012 11:38 AM To: nanog at nanog.org Subject: the topic (was: raging bulls) On Wed, Aug 08, 2012 at 11:10:41AM -0500, Naslund, Steve wrote: > We are getting a bit off the NANOG subject You think? A From valdis.kletnieks at vt.edu Wed Aug 8 11:53:23 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 08 Aug 2012 12:53:23 -0400 Subject: raging bulls In-Reply-To: Your message of "Wed, 08 Aug 2012 09:08:27 -0500." <20120808140827.GA11596@panix.com> References: <20120807122509.GC12615@leitl.org> <4E509E7E89E8441E9EDCC0439DDCFA09@owner59e1f1502> <20120808070207.GN12615@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0BC1652F@MUNEXBE1.medline.com> <20120808140827.GA11596@panix.com> Message-ID: <23728.1344444803@turing-police.cc.vt.edu> On Wed, 08 Aug 2012 09:08:27 -0500, Brett Frankenberger said: > What it's about is allowing traders to arbitrage between markets. When > product A is traded in, say, London, and product B is traded in New > York, and their prices are correlated, you can make money if your > program running in NY can learn the price of product B in London a few > milliseconds before the other guy's program. And you can make money if > your program running in London can learn the price of product A in NY a > few milliseconds before the other guy's program. If you can money off those milliseconds, then some government supervision is in order - that market is too damned volatile. I see a lot of people proposing ways to make it work, when what modern civilization needs is some market controls to make it *NOT* work. Didn't we learn our lesson the *last* time the financial system almost collapsed because financial wizards found a new way to slice and dice stuff? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From blake at pfankuch.me Wed Aug 8 13:18:04 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Wed, 8 Aug 2012 18:18:04 +0000 Subject: MXLogic outage In-Reply-To: <20120808164303.GA6358@esri.com> References: <20120808164303.GA6358@esri.com> Message-ID: We are on .11 and .12. Our email is still a little delayed, but getting better. -----Original Message----- From: Ray Van Dolson [mailto:rvandolson at esri.com] Sent: Wednesday, August 08, 2012 10:43 AM To: nanog at nanog.org Subject: Re: MXLogic outage On Wed, Aug 08, 2012 at 04:39:04PM +0000, Blake Pfankuch wrote: > We are the same way. Phones going nuts ringing as we are an MXLogic > partner. I am slowly getting email with about a 2-3 hour delay right > now. Anyone know any more? > > -----Original Message----- > From: Duane Toler [mailto:detoler at gmail.com] > Sent: Wednesday, August 08, 2012 10:34 AM > To: nanog at nanog.org > Subject: MXLogic outage > > Probably old news by now, but MXLogic folks are having some major > issues today and not reliably receiving inbound mail. Several of our > customers are talking with MXLogic about it. > > FYI. What MX servers are your affected domains using? Ours are: 208.65.145.3 208.65.145.2 208.65.144.2 208.65.144.3 And no obvious delays currently. Ray From zachary.mcgibbon+nanog at gmail.com Wed Aug 8 13:31:49 2012 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 8 Aug 2012 14:31:49 -0400 Subject: Bell Canada outage? Message-ID: Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing table is going nuts with Bell advertising a lot of routes they shouldn't be From djahandarie at gmail.com Wed Aug 8 13:35:41 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Wed, 8 Aug 2012 14:35:41 -0400 Subject: Bell Canada outage? In-Reply-To: References: Message-ID: On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon wrote: > Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing > table is going nuts with Bell advertising a lot of routes they shouldn't be Bell leaked a full table. To add to the fun, it seems that TATA took the full table and releaked it. -- Darius Jahandarie From axisml at gmail.com Wed Aug 8 13:35:47 2012 From: axisml at gmail.com (Chris Stone) Date: Wed, 8 Aug 2012 12:35:47 -0600 Subject: Bell Canada outage? In-Reply-To: References: Message-ID: On Wed, Aug 8, 2012 at 12:31 PM, Zachary McGibbon < zachary.mcgibbon+nanog at gmail.com> wrote: > Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing > table is going nuts with Bell advertising a lot of routes they shouldn't be > Outages mailing list is reporting that Tata is having problems in Montreal affecting 'many routers'.......maybe this is related? Chris -- Chris Stone AxisInternet, Inc. www.axint.net From zachary.mcgibbon+nanog at gmail.com Wed Aug 8 13:43:17 2012 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 8 Aug 2012 14:43:17 -0400 Subject: Bell Canada outage? In-Reply-To: References: Message-ID: That's what it looked like. We are connected (@ McGill University) to RISQ and a lot of our routes started to go via RISQ->Bell instead of RISQ->CANET/Canarie On Wed, Aug 8, 2012 at 2:35 PM, Chris Stone wrote: > > On Wed, Aug 8, 2012 at 12:31 PM, Zachary McGibbon < > zachary.mcgibbon+nanog at gmail.com> wrote: > >> Anyone at Bell Canada / Sympatico can tell us what's going on? Our >> routing >> table is going nuts with Bell advertising a lot of routes they shouldn't >> be >> > > Outages mailing list is reporting that Tata is having problems in Montreal > affecting 'many routers'.......maybe this is related? > > > > Chris > > -- > Chris Stone > AxisInternet, Inc. > www.axint.net > From jsw at inconcepts.biz Wed Aug 8 13:50:41 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 8 Aug 2012 14:50:41 -0400 Subject: Bell Canada outage? In-Reply-To: References: Message-ID: On Wed, Aug 8, 2012 at 2:35 PM, Chris Stone wrote: > Outages mailing list is reporting that Tata is having problems in Montreal > affecting 'many routers'.......maybe this is related? I am a transit customer of both TATA and Bell Canada. We saw route churn and heavy packet loss via both Bell and TATA beginning at approximately 13:25 ET. It took us some time to assess the situation and deactivate both our TATA and Bell BGP sessions. It also took over 10 minutes for my BGP withdraws to propagate from Bell to their neighbors, including Level3. I would guess Bell Canada's routers all have very busy CPU. No information from either NOC yet. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From mike at sentex.net Wed Aug 8 13:58:40 2012 From: mike at sentex.net (Mike Tancsa) Date: Wed, 08 Aug 2012 14:58:40 -0400 Subject: Bell Canada outage? In-Reply-To: References: Message-ID: <5022B6E0.8040105@sentex.net> On 8/8/2012 2:50 PM, Jeff Wheeler wrote: > > It also took over 10 minutes for my BGP withdraws to propagate from > Bell to their neighbors, including Level3. I would guess Bell > Canada's routers all have very busy CPU. > I saw the same sort of behaviour from TATA. I shut my peer with them, yet TATA was still advertising to Level3 a good 15min after !??! route-views> traceroute 199.212.134.1 Type escape sequence to abort. Tracing the route to 199.212.134.1 1 vl-51.uonet1-gw.uoregon.edu (128.223.51.2) [AS 3582] 280 msec 364 msec 280 msec 2 3.xe-1-3-0.uonet10-gw.uoregon.edu (128.223.3.10) [AS 3582] 252 msec 272 msec 272 msec 3 eugn-car1-gw.nero.net (207.98.68.177) [AS 3701] 272 msec 268 msec 244 msec 4 eugn-core1-gw.nero.net (207.98.64.161) [AS 3701] 260 msec 272 msec 280 msec 5 ge-6-21.car1.Sacramento1.Level3.net (4.53.200.1) [AS 3356] 296 msec 260 msec 312 msec 6 ae-11-11.car2.Sacramento1.Level3.net (4.69.132.150) [AS 3356] [MPLS: Label 83 Exp 0] 304 msec 328 msec 376 msec 7 ae-4-4.ebr2.SanJose1.Level3.net (4.69.132.158) [AS 3356] [MPLS: Label 1123 Exp 0] 328 msec 252 msec 308 msec 8 ae-3-3.ebr1.Denver1.Level3.net (4.69.132.58) [AS 3356] [MPLS: Label 1191 Exp 0] 332 msec 240 msec 232 msec 9 ae-1-100.ebr2.Denver1.Level3.net (4.69.151.182) [AS 3356] [MPLS: Label 1189 Exp 0] 252 msec 56 msec 40 msec 10 ae-3-3.ebr1.Chicago2.Level3.net (4.69.132.62) [AS 3356] [MPLS: Label 1186 Exp 0] 72 msec 72 msec 248 msec 11 ae-1-51.edge3.Chicago3.Level3.net (4.69.138.136) [AS 3356] 200 msec 344 msec 200 msec 12 tata-level3.chicago3.level3.net (4.68.110.194) [AS 3356] 204 msec 200 msec 216 msec 13 * * * 14 if-4-2.tcore1.MTT-Montreal.as6453.net (64.86.31.17) [AS 6453] 80 msec if-13-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.32.2) [AS 6453] [MPLS: Label 3208 Exp 0] 84 msec 228 msec 15 * * * 16 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] [MPLS: Label 1678 Exp 0] 260 msec 244 msec 236 msec 17 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 272 msec if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] [MPLS: Label 3208 Exp 0] 272 msec if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 260 msec 18 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] [MPLS: Label 3208 Exp 0] 224 msec 208 msec 204 msec 19 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] [MPLS: Label 1678 Exp 0] 260 msec 344 msec 300 msec 20 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 256 msec if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] [MPLS: Label 1678 Exp 0] 240 msec if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 268 msec 21 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] [MPLS: Label 3208 Exp 0] 232 msec if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 248 msec if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] [MPLS: Label 3208 Exp 0] 256 msec 22 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] [MPLS: Label 3208 Exp 0] 232 msec 240 msec 240 msec 23 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] [MPLS: Label 1678 Exp 0] 244 msec * * 24 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 284 msec 208 msec 220 msec 25 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 204 msec 256 msec if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] [MPLS: Label 3208 Exp 0] 204 msec 26 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] [MPLS: Label 3208 Exp 0] 224 msec 424 msec 208 msec 27 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] [MPLS: Label 1678 Exp 0] 220 msec * * 28 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] [MPLS: Label 1678 Exp 0] 136 msec 128 msec if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 116 msec 29 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] [MPLS: Label 3208 Exp 0] 128 msec 124 msec 116 msec 30 * 152 msec 120 msec route-views> -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From zachary.mcgibbon+nanog at gmail.com Wed Aug 8 14:05:55 2012 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 8 Aug 2012 15:05:55 -0400 Subject: Bell Canada outage? In-Reply-To: <5022B6E0.8040105@sentex.net> References: <5022B6E0.8040105@sentex.net> Message-ID: This is what we saw via our upstream provider, it happened twice: [image: Inline image 1] On Wed, Aug 8, 2012 at 2:58 PM, Mike Tancsa wrote: > On 8/8/2012 2:50 PM, Jeff Wheeler wrote: > > > > It also took over 10 minutes for my BGP withdraws to propagate from > > Bell to their neighbors, including Level3. I would guess Bell > > Canada's routers all have very busy CPU. > > > > I saw the same sort of behaviour from TATA. I shut my peer with them, > yet TATA was still advertising to Level3 a good 15min after !??! > > route-views> traceroute 199.212.134.1 > > Type escape sequence to abort. > Tracing the route to 199.212.134.1 > > 1 vl-51.uonet1-gw.uoregon.edu (128.223.51.2) [AS 3582] 280 msec 364 > msec 280 msec > 2 3.xe-1-3-0.uonet10-gw.uoregon.edu (128.223.3.10) [AS 3582] 252 msec > 272 msec 272 msec > 3 eugn-car1-gw.nero.net (207.98.68.177) [AS 3701] 272 msec 268 msec > 244 msec > 4 eugn-core1-gw.nero.net (207.98.64.161) [AS 3701] 260 msec 272 msec > 280 msec > 5 ge-6-21.car1.Sacramento1.Level3.net (4.53.200.1) [AS 3356] 296 msec > 260 msec 312 msec > 6 ae-11-11.car2.Sacramento1.Level3.net (4.69.132.150) [AS 3356] [MPLS: > Label 83 Exp 0] 304 msec 328 msec 376 msec > 7 ae-4-4.ebr2.SanJose1.Level3.net (4.69.132.158) [AS 3356] [MPLS: > Label 1123 Exp 0] 328 msec 252 msec 308 msec > 8 ae-3-3.ebr1.Denver1.Level3.net (4.69.132.58) [AS 3356] [MPLS: Label > 1191 Exp 0] 332 msec 240 msec 232 msec > 9 ae-1-100.ebr2.Denver1.Level3.net (4.69.151.182) [AS 3356] [MPLS: > Label 1189 Exp 0] 252 msec 56 msec 40 msec > 10 ae-3-3.ebr1.Chicago2.Level3.net (4.69.132.62) [AS 3356] [MPLS: Label > 1186 Exp 0] 72 msec 72 msec 248 msec > 11 ae-1-51.edge3.Chicago3.Level3.net (4.69.138.136) [AS 3356] 200 msec > 344 msec 200 msec > 12 tata-level3.chicago3.level3.net (4.68.110.194) [AS 3356] 204 msec > 200 msec 216 msec > 13 * * * > 14 if-4-2.tcore1.MTT-Montreal.as6453.net (64.86.31.17) [AS 6453] 80 msec > if-13-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.32.2) [AS 6453] > [MPLS: Label 3208 Exp 0] 84 msec 228 msec > 15 * * * > 16 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] > [MPLS: Label 1678 Exp 0] 260 msec 244 msec 236 msec > 17 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 272 > msec > if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] > [MPLS: Label 3208 Exp 0] 272 msec > if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 260 > msec > 18 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] > [MPLS: Label 3208 Exp 0] 224 msec 208 msec 204 msec > 19 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] > [MPLS: Label 1678 Exp 0] 260 msec 344 msec 300 msec > 20 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 256 > msec > if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] > [MPLS: Label 1678 Exp 0] 240 msec > if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 268 > msec > 21 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] > [MPLS: Label 3208 Exp 0] 232 msec > if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 248 > msec > if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] > [MPLS: Label 3208 Exp 0] 256 msec > 22 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] > [MPLS: Label 3208 Exp 0] 232 msec 240 msec 240 msec > 23 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] > [MPLS: Label 1678 Exp 0] 244 msec * * > 24 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 284 > msec 208 msec 220 msec > 25 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 204 > msec 256 msec > if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] > [MPLS: Label 3208 Exp 0] 204 msec > 26 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] > [MPLS: Label 3208 Exp 0] 224 msec 424 msec 208 msec > 27 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] > [MPLS: Label 1678 Exp 0] 220 msec * * > 28 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453] > [MPLS: Label 1678 Exp 0] 136 msec 128 msec > if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 116 > msec > 29 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453] > [MPLS: Label 3208 Exp 0] 128 msec 124 msec 116 msec > 30 * 152 msec 120 msec > route-views> > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike at sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > > -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 31671 bytes Desc: not available URL: From andree+nanog at toonk.nl Wed Aug 8 14:50:14 2012 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 08 Aug 2012 12:50:14 -0700 Subject: Bell Canada outage? In-Reply-To: References: Message-ID: <5022C2F6.4080400@toonk.nl> Hi, .-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius Jahandarie wrote: > On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon > wrote: >> Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing >> table is going nuts with Bell advertising a lot of routes they shouldn't be > > Bell leaked a full table. To add to the fun, it seems that TATA took > the full table and releaked it. A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems to have happened is that they leaked routes learned from VIDEOTRON to Bell. Based on BGP data I see that at 17:27 UTC AS46618 ( Dery Telecom Inc) started to leak a 'full table', or at least a significant chunk of it to its provider Bell AS577. Bell propagated that to it's peers. Tata was one of the ones that accepted all of that. I can see that Bell propagated at least 74,109 prefixes learned from AS46618 to Tata. Tata selected 70,160 of those routes. Cheers, Andree From jared at puck.nether.net Wed Aug 8 14:55:15 2012 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 8 Aug 2012 15:55:15 -0400 Subject: Bell Canada outage? In-Reply-To: <5022C2F6.4080400@toonk.nl> References: <5022C2F6.4080400@toonk.nl> Message-ID: On Aug 8, 2012, at 3:50 PM, Andree Toonk wrote: > Hi, > > .-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius > Jahandarie wrote: >> On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon >> wrote: >>> Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing >>> table is going nuts with Bell advertising a lot of routes they shouldn't be >> >> Bell leaked a full table. To add to the fun, it seems that TATA took >> the full table and releaked it. > > A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the > cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems > to have happened is that they leaked routes learned from VIDEOTRON to Bell. > > Based on BGP data I see that at 17:27 UTC AS46618 ( Dery Telecom Inc) > started to leak a 'full table', or at least a significant chunk of it to > its provider Bell AS577. > Bell propagated that to it's peers. Tata was one of the ones that > accepted all of that. > > I can see that Bell propagated at least 74,109 prefixes learned from > AS46618 to Tata. Tata selected 70,160 of those routes. Taking a cursory look at the data processed by my now (very old) leak auditing tool, this should give you an idea of the size of the impact... bgp=# select count(*) from leakinfo where aprox_time::date='2012-08-08'; count ------- 21212 bgp=# select count(*) from leakinfo where aprox_time::date='2012-08-07'; count ------- 3681 bgp=# select count(*) from leakinfo where aprox_time::date='2012-08-06'; count ------- 2428 You can see details of this at the leak info page here: http://puck.nether.net/bgp/leakinfo.cgi - Jared From tom.taylor.stds at gmail.com Wed Aug 8 15:03:21 2012 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Wed, 08 Aug 2012 16:03:21 -0400 Subject: IPTV, Multicast, and IPv6 Transition Message-ID: <5022C609.7050203@gmail.com> This may be way off in the future for some of you, or others may be past it. In support of possible work on IPv6 transition in the IETF MBONED Working Group, I'm looking for an indication of what use cases are realistic for operators who: -- deliver IPTV to their customers -- use multicast for the purpose, either now or in the near future -- are making the transition from IPv4 to IPv6. First question: does anyone anticipate a situation where you will have to translate multicast content from a IPv4-only source so it can be delivered to an IPv6-only receiver, or vice versa? Second question: the current official view is that dual stack is the sensible way to transition your network, and failing that, you can use Automatic Multicast Tunneling, an almost-ready Internet Draft available at http://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/ to tunnel multicast packets through a single-stack network when necessary. Do you consider your requirements adequately addressed by this view? People who really want to be helpful can comment on the problem statement and use cases documented in http://datatracker.ietf.org/doc/draft-ietf-mboned-v4v6-mcast-ps/ Thanks for your attention. Privacy will be respected if people want to reply privately. Tom Taylor Consultant From Kapeel.Sharma at McKesson.com Wed Aug 8 15:03:44 2012 From: Kapeel.Sharma at McKesson.com (Sharma, Kapeel) Date: Wed, 8 Aug 2012 20:03:44 +0000 Subject: Bell Canada outage? In-Reply-To: <5022C2F6.4080400@toonk.nl> References: <5022C2F6.4080400@toonk.nl> Message-ID: <247429C70AB9D948A4DDECDFA5C23390352707E1@DDCEP50016.na.corp.mckesson.com> Could this be causing issue with XO in east coast ? -----Original Message----- From: Andree Toonk [mailto:andree+nanog at toonk.nl] Sent: Wednesday, August 08, 2012 12:50 PM To: nanog at nanog.org Subject: Re: Bell Canada outage? Hi, .-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius Jahandarie wrote: > On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon > wrote: >> Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing >> table is going nuts with Bell advertising a lot of routes they shouldn't be > > Bell leaked a full table. To add to the fun, it seems that TATA took > the full table and releaked it. A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems to have happened is that they leaked routes learned from VIDEOTRON to Bell. Based on BGP data I see that at 17:27 UTC AS46618 ( Dery Telecom Inc) started to leak a 'full table', or at least a significant chunk of it to its provider Bell AS577. Bell propagated that to it's peers. Tata was one of the ones that accepted all of that. I can see that Bell propagated at least 74,109 prefixes learned from AS46618 to Tata. Tata selected 70,160 of those routes. Cheers, Andree From zachary.mcgibbon+nanog at gmail.com Wed Aug 8 15:10:22 2012 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 8 Aug 2012 16:10:22 -0400 Subject: Bell Canada outage? In-Reply-To: <5022C2F6.4080400@toonk.nl> References: <5022C2F6.4080400@toonk.nl> Message-ID: Thanks for the info, looks like Bell needs to put some filtering on their customer links! Things seem to have calmed down now but I'm still watching my prefixes received from my upstream provider: while true; do snmpget -v2c -c 1.3.6.1.4.1.9.9.187.1.2.4.1.1..1.128; sleep 1; done I also monitor all my prefixes and bgp messages in Cacti On Wed, Aug 8, 2012 at 3:50 PM, Andree Toonk wrote: > Hi, > > .-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius > Jahandarie wrote: > > On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon > > wrote: > >> Anyone at Bell Canada / Sympatico can tell us what's going on? Our > routing > >> table is going nuts with Bell advertising a lot of routes they > shouldn't be > > > > Bell leaked a full table. To add to the fun, it seems that TATA took > > the full table and releaked it. > > A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the > cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems > to have happened is that they leaked routes learned from VIDEOTRON to Bell. > > Based on BGP data I see that at 17:27 UTC AS46618 ( Dery Telecom Inc) > started to leak a 'full table', or at least a significant chunk of it to > its provider Bell AS577. > Bell propagated that to it's peers. Tata was one of the ones that > accepted all of that. > > I can see that Bell propagated at least 74,109 prefixes learned from > AS46618 to Tata. Tata selected 70,160 of those routes. > > > Cheers, > Andree > > > > > > > > From chk at pobox.com Wed Aug 8 15:11:56 2012 From: chk at pobox.com (Harald Koch) Date: Wed, 8 Aug 2012 16:11:56 -0400 Subject: Bell Canada outage? In-Reply-To: References: <5022C2F6.4080400@toonk.nl> Message-ID: On 8 August 2012 16:10, Zachary McGibbon wrote: > Thanks for the info, looks like Bell needs to put some filtering on their > customer links! > I remember when AS577 had those... ;) -- Harald From steve+nanog at sendithere.com Wed Aug 8 15:14:37 2012 From: steve+nanog at sendithere.com (Steve Dalberg) Date: Wed, 8 Aug 2012 13:14:37 -0700 Subject: Bell Canada outage? In-Reply-To: References: Message-ID: CPU's were pegged for a customer of mine in California. tracked it down to 2 events that went down at that time with a large message volume. 1) Peering between GLBX and Level3 dopped somewhere, causing many prefixes to shift away from L3 paths. 2) Some IPv6 prefixes were aggressively bouncing from HE starting at 11:25. Can't trace it any further upstream for HE unfortunately. This cause lots of CPU churn on one of my customers networks May or may not be related. -- Steve From andree+nanog at toonk.nl Wed Aug 8 15:31:58 2012 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 08 Aug 2012 13:31:58 -0700 Subject: Bell Canada outage? In-Reply-To: <5022C2F6.4080400@toonk.nl> References: <5022C2F6.4080400@toonk.nl> Message-ID: <5022CCBE.3020307@toonk.nl> Further analysis shows that there were actually 107,409 prefixes affected of 14,391 unique origin ASn's. Interested if your prefixes was affected? I've uploaded a list of prefixes and ASn's that were leaked here: http://www.bgpmon.net/bell-leak.txt Cheers, Andree .-- My secret spy satellite informs me that at 12-08-08 12:50 PM Andree Toonk wrote: > Hi, > > .-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius > Jahandarie wrote: >> On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon >> wrote: >>> Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing >>> table is going nuts with Bell advertising a lot of routes they shouldn't be >> >> Bell leaked a full table. To add to the fun, it seems that TATA took >> the full table and releaked it. > > A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the > cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems > to have happened is that they leaked routes learned from VIDEOTRON to Bell. > > Based on BGP data I see that at 17:27 UTC AS46618 ( Dery Telecom Inc) > started to leak a 'full table', or at least a significant chunk of it to > its provider Bell AS577. > Bell propagated that to it's peers. Tata was one of the ones that > accepted all of that. > > I can see that Bell propagated at least 74,109 prefixes learned from > AS46618 to Tata. Tata selected 70,160 of those routes. > > > Cheers, > Andree > > > > > > > From zachary.mcgibbon+nanog at gmail.com Wed Aug 8 15:34:55 2012 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 8 Aug 2012 16:34:55 -0400 Subject: Bell Canada outage? In-Reply-To: <5022CCBE.3020307@toonk.nl> References: <5022C2F6.4080400@toonk.nl> <5022CCBE.3020307@toonk.nl> Message-ID: Ouch!! That's a lot! What do you think the outcome of this will be? What do you think that Bell did/will do (hopefully) to fix this so it doesn't happen again? On Wed, Aug 8, 2012 at 4:31 PM, Andree Toonk wrote: > Further analysis shows that there were actually 107,409 prefixes > affected of 14,391 unique origin ASn's. > > Interested if your prefixes was affected? > I've uploaded a list of prefixes and ASn's that were leaked here: > http://www.bgpmon.net/bell-leak.txt > > Cheers, > Andree > > > > .-- My secret spy satellite informs me that at 12-08-08 12:50 PM Andree > Toonk wrote: > > Hi, > > > > .-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius > > Jahandarie wrote: > >> On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon > >> wrote: > >>> Anyone at Bell Canada / Sympatico can tell us what's going on? Our > routing > >>> table is going nuts with Bell advertising a lot of routes they > shouldn't be > >> > >> Bell leaked a full table. To add to the fun, it seems that TATA took > >> the full table and releaked it. > > > > A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the > > cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems > > to have happened is that they leaked routes learned from VIDEOTRON to > Bell. > > > > Based on BGP data I see that at 17:27 UTC AS46618 ( Dery Telecom Inc) > > started to leak a 'full table', or at least a significant chunk of it to > > its provider Bell AS577. > > Bell propagated that to it's peers. Tata was one of the ones that > > accepted all of that. > > > > I can see that Bell propagated at least 74,109 prefixes learned from > > AS46618 to Tata. Tata selected 70,160 of those routes. > > > > > > Cheers, > > Andree > > > > > > > > > > > > > > > > > From dmiller at tiggee.com Wed Aug 8 15:49:55 2012 From: dmiller at tiggee.com (David Miller) Date: Wed, 08 Aug 2012 16:49:55 -0400 Subject: Bell Canada outage? In-Reply-To: References: Message-ID: <5022D0F3.6050404@tiggee.com> On 8/8/2012 4:14 PM, Steve Dalberg wrote: > CPU's were pegged for a customer of mine in California. tracked it > down to 2 events that went down at that time with a large message > volume. > > 1) Peering between GLBX and Level3 dopped somewhere, causing many > prefixes to shift away from L3 paths. FYI: We saw significant route churn on GBLX (AS3549) as well as on Tata. > 2) Some IPv6 prefixes were aggressively bouncing from HE starting at > 11:25. Can't trace it any further upstream for HE unfortunately. > This cause lots of CPU churn on one of my customers networks > > May or may not be related. > From jim at neuse.net Wed Aug 8 16:04:01 2012 From: jim at neuse.net (Jim Ray) Date: Wed, 8 Aug 2012 17:04:01 -0400 Subject: next hop packet loss In-Reply-To: References: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local><50203C33.9040506@ninjabadger.net><5be2f848f21f8348447f2e4fc9738420.squirrel@g.mail.aa.net.uk><530DFF0280267643A67908BB181189E5981DE9@garcia.neuse.local> Message-ID: <530DFF0280267643A67908BB181189E5981E0D@garcia.neuse.local> They've had me blocked for a few weeks now. I've always been able to reach it on Verizon network with iPhone, just not with Time Warner Business Class. I plan to take advice from kind members of group that offered it and investigate a little more with Wireshark yet have been in middle of client migration of aging Exchange 2003 server to 2010 version in the cloud since Friday. http://www.CheckPoint.com can wait. I had a great face to face meeting with person from another UTM company this morning http://www.sophos.com Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com -----Original Message----- From: Eugeniu Patrascu [mailto:eugen at imacandi.net] Sent: Wednesday, August 08, 2012 5:07 AM To: Jim Ray Cc: tom at ninjabadger.net; nanog at nanog.org Subject: Re: next hop packet loss On Tue, Aug 7, 2012 at 4:12 PM, Jim Ray wrote: > Sorry, I do not give verbose responses via iPhone on that small device > with my tired old eyes. I ran Wireshark this morning. > > Without sniffing packets, the layman's description of problem is "I > can't get to vendor web site, http://www.CheckPoint.com, on Time > Warner Business Class network I use." Hence, http is blocked in > addition to ICMP. > Yesterday, Check Point's website was unreachable from other parts of the world for some time with intermittent access for around an hour or so I believe. Eugeniu From jsw at inconcepts.biz Wed Aug 8 16:54:50 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 8 Aug 2012 17:54:50 -0400 Subject: Bell Canada outage? In-Reply-To: References: <5022C2F6.4080400@toonk.nl> Message-ID: We have been advised that TATA/6453 is back to normal, and re-activated our BGP to them. Everything seems okay on this front. No update from Bell Canada yet. On Wed, Aug 8, 2012 at 4:11 PM, Harald Koch wrote: > On 8 August 2012 16:10, Zachary McGibbon >> Thanks for the info, looks like Bell needs to put some filtering on their >> customer links! > > I remember when AS577 had those... ;) We actually have asked Bell Canada not to filter routes from us, and use prefix-limit only, because they were not able to build a prefix-list for us if we have any downstream customer ASNs, which we do. :-/ If someone at Bell Canada is reading and cared to contact me off-list, I would sure love to get my own route filtering fixed. I have had little success through the normal channels. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From up at 3.am Wed Aug 8 16:58:57 2012 From: up at 3.am (up at 3.am) Date: Wed, 8 Aug 2012 17:58:57 -0400 Subject: Bell Canada outage? In-Reply-To: References: Message-ID: <2746776ef6624d7ccd15d620b2d44bb8.squirrel@ssl.pil.net> > > Hi, > > .-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius > Jahandarie wrote: >> On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon >> wrote: >>> Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing >>> table is going nuts with Bell advertising a lot of routes they shouldn't be >> >> Bell leaked a full table. To add to the fun, it seems that TATA took >> the full table and releaked it. > > A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the > cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems > to have happened is that they leaked routes learned from VIDEOTRON to Bell. > > Based on BGP data I see that at 17:27 UTC AS46618 ( Dery Telecom Inc) > started to leak a 'full table', or at least a significant chunk of it to > its provider Bell AS577. > Bell propagated that to it's peers. Tata was one of the ones that > accepted all of that. > > I can see that Bell propagated at least 74,109 prefixes learned from > AS46618 to Tata. Tata selected 70,160 of those routes. Interesting. I have a server hosted on Bell Canada's network and I saw an outage of about 30 minutes today, but it ONLY affected connections from Verizon's network. This includes my own FIOS connection. I still could connect to the server through Comcast, Level 3 and XO with no problems. Traceroutes from my Verizon IP only got 2 hops, stopping at a philly router and traceroutes back to the same IP from that server got as far as NYC. From jim at neuse.net Wed Aug 8 18:39:12 2012 From: jim at neuse.net (Jim Ray) Date: Wed, 8 Aug 2012 19:39:12 -0400 Subject: next hop packet loss In-Reply-To: References: <530DFF0280267643A67908BB181189E5981DE2@garcia.neuse.local> Message-ID: <530DFF0280267643A67908BB181189E5981E18@garcia.neuse.local> telnet www.checkpoint.com 80 GET / HTTP/1.1 Host: www.checkpoint.com ...resolved some information and then lost connection according to this trailer from the screen scrape:
>
>