RE: 99% of HK internet traffic goes thru uni being fought over?
On 21 November 2019 23:48:33 CET, "Mahmutovic, Jas" wrote: >Excerpt from http://www.hkix.net/hkix/Presentation/forum20100129.pdf >(Page 3) > > Two Main Sites for resilience > >•HKIX1: CUHK Campus in Shatin >•HKIX2: CITIC Tower in Central > > We are confident to say that because of HKIX, more than 99% intra--HK >Internet traffic is kept within HK > > And this is a completely different thing than saying that 99% of HKG traffic passes through HKIX. Written this way it may as well be true since it only means that it neatly complements whatever transit and private peering arrangements the local operators have. Exercise for the reader: - find out who the local access providers are - find where they peer and at what capacity - find who gives them transit - try some traceroutes After this you'll concur with my original assessment about the nitrates content of the statement at subject -- Pierfrancesco Caci
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
Probably because a market would quickly pop up to sell or rent accounts created in one region to others. On Thu, Nov 21, 2019, 2:32 AM t...@pelican.org wrote: > On Wednesday, 20 November, 2019 21:25, "William Herrin" > said: > > > This is why you don't go after Hulu. You go after the content owners who > > conspired to compel Hulu to limit distribution in a way that tortiously > > interferes with your contract with your eyeball customers. > > Am I the only one who's baffled in the context of a paid service why so > much focus is put on where the consumption takes place (hard), and so > little on where the transaction take place (easy)? > > I understand, even if I don't necessarily always agree with, market > segmentation, differentiated pricing, accurate P for different business > units, etc, that mean for example if you're a US citizen you need to pay > Disney US the prevailing US price to watch Disney content, but if you're an > EU citizen you need to pay Disney EMEA the prevailing EU price to watch > Disney content. Surely that transaction is the thing content creators and > distributors care about? > > If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to > the US and watch them on my laptop, no-one is screaming that I'm violating > someone's geographic distribution rights by doing so. If a US citizen is > paying for Hulu, from a US billing address, on a US credit card, but > happens to be watching from their hotel in Italy, why does anyone care? > > I can see why it's different and more complicated for content that's > provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation > for paid services seems a terrible waste of time and effort on both sides. > > Or am I woefully naive, and it's actually trivial for a non-US resident to > come up with a US credit card and billing address to pay for the service? > > Regards, > Tim. > > > > On Thu, Nov 21, 2019, 2:32 AM t...@pelican.org wrote: > On Wednesday, 20 November, 2019 21:25, "William Herrin" > said: > > > This is why you don't go after Hulu. You go after the content owners who > > conspired to compel Hulu to limit distribution in a way that tortiously > > interferes with your contract with your eyeball customers. > > Am I the only one who's baffled in the context of a paid service why so > much focus is put on where the consumption takes place (hard), and so > little on where the transaction take place (easy)? > > I understand, even if I don't necessarily always agree with, market > segmentation, differentiated pricing, accurate P for different business > units, etc, that mean for example if you're a US citizen you need to pay > Disney US the prevailing US price to watch Disney content, but if you're an > EU citizen you need to pay Disney EMEA the prevailing EU price to watch > Disney content. Surely that transaction is the thing content creators and > distributors care about? > > If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to > the US and watch them on my laptop, no-one is screaming that I'm violating > someone's geographic distribution rights by doing so. If a US citizen is > paying for Hulu, from a US billing address, on a US credit card, but > happens to be watching from their hotel in Italy, why does anyone care? > > I can see why it's different and more complicated for content that's > provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation > for paid services seems a terrible waste of time and effort on both sides. > > Or am I woefully naive, and it's actually trivial for a non-US resident to > come up with a US credit card and billing address to pay for the service? > > Regards, > Tim. > > > >
Re: Question about normal ops - BGP Flaps nightly
On Fri, Nov 22, 2019 at 12:40 PM Christopher Morrow wrote: > > On Fri, Nov 22, 2019 at 12:32 PM Baldur Norddahl > wrote: > > > > > > > > On Fri, Nov 22, 2019 at 1:21 AM Christopher Morrow > > wrote: > >> > >> On Fri, Nov 22, 2019 at 2:01 AM Saku Ytti wrote: > >> > > >> > On Thu, 21 Nov 2019 at 19:44, Baldur Norddahl > >> > wrote: > >> > > >> > > A BGP reset can cause routing trouble for as much as 15 minutes. Since > >> > > you have two sessions that mitigates the problem somewhat. But > >> > > nevertheless this will not be acceptable. > >> > > >> > As there are best path algorithms which consider route age, BGP reset > >> > impact may be indefinite. > >> > >> fortunately we have a second actual provider... so this all isn't > >> super impacting to us, just weird and unexpected on my part. > >> > > > > No that is not helping. When the BGP session flaps your routes via that > > provider are withdrawn. Everyone out there that were using those routes > > will need to switch. But consider the following: > > > > ISP A has routes from both of your providers > > ISP B has A as uplink > > > > BGP works so that ISP A is only announcing the route that he is actually > > using to ISP B. ISP B therefore does not have both of your routes. When the > > active route is withdrawn ISP B will momentary be without any route to your > > network. It can take some time after the withdraw before ISP A announces > > that he now is using the alternative route. This gets worse with longer > > chains. Also some ISPs are using route flap limiting techniques that can > > prolong this process. > > > > As I said, my experience is that you can expect as much as 15 minutes of > > flaky internet after a BGP reset. This is with multiple transit providers. > > Yup, I'm sensitive to flapping causing problems. This was why i > started the thread, which really should have been: > "Is there a well known bug people are working around? or is this a > new problem I should chase with the provider? or 'nah, everyone does > this, you just aren't normally paying attention'" > > > > > I can not say too much about why you have BGP resets, but I can say that > > you really want it fixed. It will affect your connectivity. > > > > fortunately 3am local time is not prime-internet-use time :) phew! > (not a great excuse though, of course) > The other saving grace / "meh" is that this is for a conference network, and we are picking up sticks and leaving tomorrow... so, we will let the provider know that there is something that should be fixed, but a: our pain will have stopped :-P and b: we won't really have a good way to know if they have fixed the issue (other than perhaps watching for a spike of withdraws / reannouncements every 24 hours through this AS path) W > I'll be chasing up the provider to see what's up. > thanks! > -chris > > > Regards, > > > > Baldur > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Re: Question about normal ops - BGP Flaps nightly
On Fri, Nov 22, 2019 at 12:32 PM Baldur Norddahl wrote: > > > > On Fri, Nov 22, 2019 at 1:21 AM Christopher Morrow > wrote: >> >> On Fri, Nov 22, 2019 at 2:01 AM Saku Ytti wrote: >> > >> > On Thu, 21 Nov 2019 at 19:44, Baldur Norddahl >> > wrote: >> > >> > > A BGP reset can cause routing trouble for as much as 15 minutes. Since >> > > you have two sessions that mitigates the problem somewhat. But >> > > nevertheless this will not be acceptable. >> > >> > As there are best path algorithms which consider route age, BGP reset >> > impact may be indefinite. >> >> fortunately we have a second actual provider... so this all isn't >> super impacting to us, just weird and unexpected on my part. >> > > No that is not helping. When the BGP session flaps your routes via that > provider are withdrawn. Everyone out there that were using those routes will > need to switch. But consider the following: > > ISP A has routes from both of your providers > ISP B has A as uplink > > BGP works so that ISP A is only announcing the route that he is actually > using to ISP B. ISP B therefore does not have both of your routes. When the > active route is withdrawn ISP B will momentary be without any route to your > network. It can take some time after the withdraw before ISP A announces that > he now is using the alternative route. This gets worse with longer chains. > Also some ISPs are using route flap limiting techniques that can prolong this > process. > > As I said, my experience is that you can expect as much as 15 minutes of > flaky internet after a BGP reset. This is with multiple transit providers. Yup, I'm sensitive to flapping causing problems. This was why i started the thread, which really should have been: "Is there a well known bug people are working around? or is this a new problem I should chase with the provider? or 'nah, everyone does this, you just aren't normally paying attention'" > > I can not say too much about why you have BGP resets, but I can say that you > really want it fixed. It will affect your connectivity. > fortunately 3am local time is not prime-internet-use time :) phew! (not a great excuse though, of course) I'll be chasing up the provider to see what's up. thanks! -chris > Regards, > > Baldur >
Re: Question about normal ops - BGP Flaps nightly
On Fri, Nov 22, 2019 at 1:21 AM Christopher Morrow wrote: > On Fri, Nov 22, 2019 at 2:01 AM Saku Ytti wrote: > > > > On Thu, 21 Nov 2019 at 19:44, Baldur Norddahl > wrote: > > > > > A BGP reset can cause routing trouble for as much as 15 minutes. Since > you have two sessions that mitigates the problem somewhat. But nevertheless > this will not be acceptable. > > > > As there are best path algorithms which consider route age, BGP reset > > impact may be indefinite. > > fortunately we have a second actual provider... so this all isn't > super impacting to us, just weird and unexpected on my part. > > No that is not helping. When the BGP session flaps your routes via that provider are withdrawn. Everyone out there that were using those routes will need to switch. But consider the following: ISP A has routes from both of your providers ISP B has A as uplink BGP works so that ISP A is only announcing the route that he is actually using to ISP B. ISP B therefore does not have both of your routes. When the active route is withdrawn ISP B will momentary be without any route to your network. It can take some time after the withdraw before ISP A announces that he now is using the alternative route. This gets worse with longer chains. Also some ISPs are using route flap limiting techniques that can prolong this process. As I said, my experience is that you can expect as much as 15 minutes of flaky internet after a BGP reset. This is with multiple transit providers. I can not say too much about why you have BGP resets, but I can say that you really want it fixed. It will affect your connectivity. Regards, Baldur
Re: Question about normal ops - BGP Flaps nightly
On Fri, Nov 22, 2019 at 2:01 AM Saku Ytti wrote: > > On Thu, 21 Nov 2019 at 19:44, Baldur Norddahl > wrote: > > > A BGP reset can cause routing trouble for as much as 15 minutes. Since you > > have two sessions that mitigates the problem somewhat. But nevertheless > > this will not be acceptable. > > As there are best path algorithms which consider route age, BGP reset > impact may be indefinite. fortunately we have a second actual provider... so this all isn't super impacting to us, just weird and unexpected on my part. > > -- > ++ytti
Re: Question about normal ops - BGP Flaps nightly
On Fri, Nov 22, 2019 at 12:54 AM Tom Beecher wrote: > > I agree that this sounds like an automated process in some way. > > I would suspect that either a vendor code update changed something such that > a given command that would not cause session reset now does, or they changed > their automation to include a command that would cause a reset without > realizing it/slipped through the cracks / etc. > thanks to some private chat with another nanog participant it was noted the reason for failure is: "Error event Operation timed out(60) for I/O session - closing it" This is fine, I suppose, except that I have v4/v6 sessions on the same ptp link/path. So, if v6 times out I'd have expected v4 to also timeout. Strangely I had thought we were told the 2 links we have land on 2 different devices, but router-id tells me that's false as well. :( The sessions appear to reset on both devices (according to syslog) at the same time, I had thought (because our alerter is telling me) the sessions had a gap between the 2 drops. The physical payer is some bidi fiber path across an L2 (ether) network to the provider, perhaps the problem isn't on the l3/bgp parts here, but in the l2 network between. we are at the end of our time here so I think I'll gather some logs and see if the provider can make sense of the issues. > On Thu, Nov 21, 2019 at 9:18 AM Mel Beckman wrote: >> >> No. There should be no reason to bounce the session. Do you have soft >> updates turn on? >> >> -mel via cell >> >> > On Nov 21, 2019, at 1:46 AM, Christopher Morrow >> > wrote: >> > >> > Howdy! >> > A question of interest to me, currently, is whether it's normal for >> > providers to cause BGP flaps to their customers nightly... This seems, >> > in my case, to be the provider PROBABLY updating prefix-filters on my >> > session(s). >> > >> > Particularly AS56554 is currently getting v4/v6 transit from 2 >> > providers, one of which we have 2 links toward. That provider appears >> > to flap both of our ipv6 (only) bgp peers each night at about the same >> > time each night. This smells like: "filter updates', but something >> > that's different than the v4 filter update? (or perhaps they have no >> > v4 filtering to update?) >> > >> > In the end, should customers expect nightly (or on a regular cadence) >> > to see their sessions bounce? It hasn't been my experience in other >> > situations... >> > >> > -chris
[NANOG-announce] NANOG 78 call for presentations is open
NANOG Community, The NANOG Program Committee (PC) is excited to announce that we are now accepting proposals for all sessions at NANOG 78 in San Francisco, California, February 10-12, 2020. Below is a summary of key details and dates from the Call For Presentations on the NANOG website, which can be found at https://www.nanog.org/meetings/nanog-78/submit-presentation/ Given by many of the industry’s top minds, presentations at NANOG meetings are meant to spark the imagination, encourage dialog, and drive new solutions to our greatest networking challenges. The PC is currently seeking proposals, and also welcomes suggestions for speakers and topics. Presentations may cover current technologies, soon-to-be deployed technologies, and industry innovation. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations should not be promotional, or discuss proprietary solutions. The primary speaker, moderator, or author should submit a presentation proposal and abstract via the Program Committee Tool at: https://www.nanog.org/meetings/submit-presentation/ - Sign in with your Profile Account - Select the type of talk you propose to present, and complete the title and abstract Timeline for submission and proposal review: - Submitter enters abstract (and draft slides if possible) in Program Committee Tool prior to the deadline for slide submission. - PC performs initial review and assigns a “shepherd” to help develop the submission — within 2 weeks. - Submitter develops draft slides of talk if not already submitted with the initial proposal. Please submit initial draft slides early — the PC does not evaluate submissions until draft slides are available for review. NANOG Staff is available to assist with slide templates upon request from the submitter. - Panel and Track submissions should provide a topic list and intended/confirmed participants in the abstract. - PC reviews the slides and continues to work with Submitter as needed to develop the topic. - Draft presentation slides should be submitted prior to the published deadline for slides (Dec. 30, 2019). - PC evaluates submissions to determine presentations for the agenda (posted on Jan. 27, 2020). - Agenda assembled and posted. - Submitters notified. - Final presentation slides must be submitted prior to the published deadline for slides (Feb. 3, 2020). If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the PC ( nano...@nanog.org), and a representative will respond to you in a timely manner. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool at your earliest convenience. We look forward to reviewing your submission! Key dates for NANOG 78: Date Event/Deadline Nov. 18, 2019 CFP Opens Dec. 16, 2019 Standard Registration Begins Dec. 30, 2019 CFP Deadline: Presentation Slides Due Jan. 13, 2020 CFP Topic List & NANOG Meeting HIghlights Page posted Jan. 20, 2020 Late Registration Begins Jan. 27, 2020 NANOG 78 Agenda Posted Feb. 3, 2020 Speaker FINAL presentations DUE (NO CHANGES accepted after this date) Feb. 9, 2020 Lightning Talk Submissions Open, Onsite Registration Begins Final slides must be submitted by Monday, February 3, 2020, and no changes will be accepted between that date and the conference. Materials received after that date may be updated on the website after the completion of the conference. We look forward to seeing you in February in San Francisco, California! Sincerely, Vincent Celindro - PC Chair On behalf of the NANOG Program Committee ___ NANOG-announce mailing list NANOG-announce@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce
NANOG 78 call for presentations is open
NANOG Community, The NANOG Program Committee (PC) is excited to announce that we are now accepting proposals for all sessions at NANOG 78 in San Francisco, California, February 10-12, 2020. Below is a summary of key details and dates from the Call For Presentations on the NANOG website, which can be found at https://www.nanog.org/meetings/nanog-78/submit-presentation/ Given by many of the industry’s top minds, presentations at NANOG meetings are meant to spark the imagination, encourage dialog, and drive new solutions to our greatest networking challenges. The PC is currently seeking proposals, and also welcomes suggestions for speakers and topics. Presentations may cover current technologies, soon-to-be deployed technologies, and industry innovation. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations should not be promotional, or discuss proprietary solutions. The primary speaker, moderator, or author should submit a presentation proposal and abstract via the Program Committee Tool at: https://www.nanog.org/meetings/submit-presentation/ - Sign in with your Profile Account - Select the type of talk you propose to present, and complete the title and abstract Timeline for submission and proposal review: - Submitter enters abstract (and draft slides if possible) in Program Committee Tool prior to the deadline for slide submission. - PC performs initial review and assigns a “shepherd” to help develop the submission — within 2 weeks. - Submitter develops draft slides of talk if not already submitted with the initial proposal. Please submit initial draft slides early — the PC does not evaluate submissions until draft slides are available for review. NANOG Staff is available to assist with slide templates upon request from the submitter. - Panel and Track submissions should provide a topic list and intended/confirmed participants in the abstract. - PC reviews the slides and continues to work with Submitter as needed to develop the topic. - Draft presentation slides should be submitted prior to the published deadline for slides (Dec. 30, 2019). - PC evaluates submissions to determine presentations for the agenda (posted on Jan. 27, 2020). - Agenda assembled and posted. - Submitters notified. - Final presentation slides must be submitted prior to the published deadline for slides (Feb. 3, 2020). If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the PC ( nano...@nanog.org), and a representative will respond to you in a timely manner. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool at your earliest convenience. We look forward to reviewing your submission! Key dates for NANOG 78: Date Event/Deadline Nov. 18, 2019 CFP Opens Dec. 16, 2019 Standard Registration Begins Dec. 30, 2019 CFP Deadline: Presentation Slides Due Jan. 13, 2020 CFP Topic List & NANOG Meeting HIghlights Page posted Jan. 20, 2020 Late Registration Begins Jan. 27, 2020 NANOG 78 Agenda Posted Feb. 3, 2020 Speaker FINAL presentations DUE (NO CHANGES accepted after this date) Feb. 9, 2020 Lightning Talk Submissions Open, Onsite Registration Begins Final slides must be submitted by Monday, February 3, 2020, and no changes will be accepted between that date and the conference. Materials received after that date may be updated on the website after the completion of the conference. We look forward to seeing you in February in San Francisco, California! Sincerely, Vincent Celindro - PC Chair On behalf of the NANOG Program Committee
Re: Iran cuts 95% of Internet traffic
I'm curious to see if there will be a Telecomix grass roots type resurgence to POTS. On Mon, Nov 18, 2019 at 7:11 AM Sean Donelan wrote: > > > Its very practical for a country to cut 95%+ of its Internet connectivity. > Its not a complete cut-off, there is some limited connectivity. But for > most ordinary individuals, their communication channels are cut-off. > > https://twitter.com/netblocks/status/1196366347938271232
RE: 99% of HK internet traffic goes thru uni being fought over?
Excerpt from http://www.hkix.net/hkix/Presentation/forum20100129.pdf (Page 3) Two Main Sites for resilience •HKIX1: CUHK Campus in Shatin •HKIX2: CITIC Tower in Central We are confident to say that because of HKIX, more than 99% intra--HK Internet traffic is kept within HK -Original Message- From: NANOG On Behalf Of b...@theworld.com Sent: Thursday, November 21, 2019 2:06 PM To: John Sage Cc: nanog@nanog.org; b...@theworld.com Subject: Re: 99% of HK internet traffic goes thru uni being fought over? On November 20, 2019 at 15:11 mailto:js...@finchhaven.com (John Sage) wrote: > Then, as to Internet traffic, the probability that 99% of *all* Internet > > traffic to one global political entity (Hong Kong) goes through one > > single physical location that just happens to be a university currently > > experiencing student protests is ... yeah... Interesting theory. > > I take it you know nothing about Internetworking? Perhaps you should look at https://www.TheWorld.com/~bzs > > Or, again, Zerohedge? Nope, knew nothing off-hand about them but wikipedia seems to concur that Zerohedge is likely a "Russian asset". Thanks. Nonetheless it doesn't particularly mean that 99% of HK traffic *doesn't* go thru that facility, not alone. Broad comparisons to other national internet structures as you appeal to seems to be questionable in regards to a Special Administrative Region of The People's Republic of China, albeit officially ruled under "one system, two ways", HK being one of the regions (Macau being the other) which is ruled under the "second" way. China can be unique in their communications policies and practices. Which is why I asked hoping someone knew the facts rather than had an opinion about the particular source or some theory unifying all national internet infrastructures under some simple rule of thumb. -- -Barry Shein Software Tool & Die| mailto:b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: 99% of HK internet traffic goes thru uni being fought over?
On November 20, 2019 at 15:11 js...@finchhaven.com (John Sage) wrote: > Then, as to Internet traffic, the probability that 99% of *all* Internet > traffic to one global political entity (Hong Kong) goes through one > single physical location that just happens to be a university currently > experiencing student protests is ... yeah... Interesting theory. > > I take it you know nothing about Internetworking? Perhaps you should look at https://www.TheWorld.com/~bzs > > Or, again, Zerohedge? Nope, knew nothing off-hand about them but wikipedia seems to concur that Zerohedge is likely a "Russian asset". Thanks. Nonetheless it doesn't particularly mean that 99% of HK traffic *doesn't* go thru that facility, not alone. Broad comparisons to other national internet structures as you appeal to seems to be questionable in regards to a Special Administrative Region of The People's Republic of China, albeit officially ruled under "one system, two ways", HK being one of the regions (Macau being the other) which is ruled under the "second" way. China can be unique in their communications policies and practices. Which is why I asked hoping someone knew the facts rather than had an opinion about the particular source or some theory unifying all national internet infrastructures under some simple rule of thumb. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
RE: Iran cuts 95% of Internet traffic
>"Internet penetration and complexity has vastly grown in Iran >over the past decade, but the country’s users still connect >to the global network through just two gateways. Both are >controlled by the regime, and can be blocked when it chooses." > >"Access to the internet is gradually being restored in Iran >after an unprecedented five-day shutdown that cut its population >off from the rest of the world and suppressed news of the >deadliest unrest since the country’s 1979 revolution." Gradually? How long does it take to plug in a network connection and converge BGP? Like most things it is a matter of motivation. A gun held to the head will change "gradually" into "instantly" ... it can also change "instantly" into "gradually over the next week" depending on the requirements of he who holds the gun. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: Iran cuts 95% of Internet traffic
--- eric.kuh...@gmail.com wrote: From: Eric Kuhnke The vast majority of Iranian ISPs' international transit connectivity is through AS12880 DCI , which is a government run telecom authority. Google "AS12880 DCI Iran" for more info. DCI is also responsible for layer 2 transport and DWDM services for smaller downstream ISPs, on other international terrestrial fiber links, which are opaque to us NANOG list people from the perspective of global v4/v6 routing table/prefix announcement analysis. - Quoting a journalist, so https://www.theguardian.com/world/2019/nov/21/irans-digital-shutdown-other-regimes-will-be-watching-closely First quote out of order from the article: "Internet penetration and complexity has vastly grown in Iran over the past decade, but the country’s users still connect to the global network through just two gateways. Both are controlled by the regime, and can be blocked when it chooses." "Access to the internet is gradually being restored in Iran after an unprecedented five-day shutdown that cut its population off from the rest of the world and suppressed news of the deadliest unrest since the country’s 1979 revolution." "The internet-freedom group Access Now recorded 75 internet outages in 2016, which more than doubled to 196 last year." "Iranians were cut off from the global internet, but internally, networks appeared to be functioning relatively normally." "the Iranian government has been working to develop the so-called “halal net”, a closed-off version of the internet similar to China’s “great firewall”. Iran has been pressuring businesses to shift their operations inside the country on to what it calls the National Information Network, which now boasts its own banking platforms, industrial services and messaging apps – ones that activists believe are closely surveilled by authorities." "The Trump sanctions have actually made it easier for Iran to seal its citizens off from the global internet ... Many Iranian tech firms have been left with no option but to use the Islamic Republic’s internal network and infrastructure instead." (reordered quote) "The last time Iran attempted to choke off access, during unrest in January 2018, it was forced to open connections again after just 30 minutes, Rashidi says. “It was a disaster,” he says. “Nothing was working: all the government offices, hospitals, financial services were gone ... they’ve discovered a lot of things do need access to the outside world” This time, it appears to have gone more smoothly: two sources able to monitor internet traffic inside Iran confirmed to the Guardian there was no significant disruption, indicating hospitals, financial software and even ride-sharing apps were still able to function, even as Iranians were unable to connect to websites such as Google." "Other authoritarian governments are pursuing a similar path. This month, Russia implemented a new law requiring ISPs to install equipment better able to identify the source of web traffic, as part of a strategy to one day be able to completely re-route the Russian internet through state-controlled data points." :) “Regimes around the world will be watching very closely both the public response and the response of the international community,” he says. “If it turns out this is feasible to implement, they will see there is no political cost.” scott
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
On Thu, Nov 21, 2019 at 10:22 AM Blake Hudson wrote: > t...@pelican.org wrote on 11/21/2019 4:32 AM: > > Or am I woefully naive, and it's actually trivial for a non-US resident to come up with a US credit card and billing address to pay for the service? 1. Buy a prepaid debit card. 2. Rent a mailbox at Mailboxes Etc. or a similar company. 3. Log in to the prepaid card's web site and enter the address of your rented mailbox as the billing address. > Tim, like you, I've been baffled by this choice as well. Why streaming > video providers continue to choose a costly and convoluted path when a > less convoluted and cheaper path exists to reach (seemingly) the same > destination I will never know. Again, streaming video providers did not make this choice. Content owners did, and made its enforcement a contractual requirement for leasing that content to the streaming video providers. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Google NOC contact for public APIs? (GeoIP issues with googleapis.com)
Having a bit of a weird issue where traffic from one of our data centers looks to be getting a response for googleapis.com which is in Malaysia, despite the data center being in northeast USA--assuming I'm reading the reverse DNS on the IP addresses right (228.27.217.172.in-addr.arpa domain name pointer kul09s01-in-f4.1e100.net.) Our other data centers seem to get OK DNS responses, not exactly "perfect" (Switzerland gets some "waw" (warsaw?) node when there appear to be "zrh" nodes it could get), but this response in our us-northeast facility has a 300ms+ RTT and is causing performance issues in our application. Does anyone have a contact at Google, or if someone at Google could contact me off-list, I'd appreciate it. --Neil
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
t...@pelican.org wrote on 11/21/2019 4:32 AM: On Wednesday, 20 November, 2019 21:25, "William Herrin" said: This is why you don't go after Hulu. You go after the content owners who conspired to compel Hulu to limit distribution in a way that tortiously interferes with your contract with your eyeball customers. Am I the only one who's baffled in the context of a paid service why so much focus is put on where the consumption takes place (hard), and so little on where the transaction take place (easy)? I understand, even if I don't necessarily always agree with, market segmentation, differentiated pricing, accurate P for different business units, etc, that mean for example if you're a US citizen you need to pay Disney US the prevailing US price to watch Disney content, but if you're an EU citizen you need to pay Disney EMEA the prevailing EU price to watch Disney content. Surely that transaction is the thing content creators and distributors care about? If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so. If a US citizen is paying for Hulu, from a US billing address, on a US credit card, but happens to be watching from their hotel in Italy, why does anyone care? I can see why it's different and more complicated for content that's provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation for paid services seems a terrible waste of time and effort on both sides. Or am I woefully naive, and it's actually trivial for a non-US resident to come up with a US credit card and billing address to pay for the service? Regards, Tim. Tim, like you, I've been baffled by this choice as well. Why streaming video providers continue to choose a costly and convoluted path when a less convoluted and cheaper path exists to reach (seemingly) the same destination I will never know. Perhaps one company did it that way so others just copied the mistake? Perhaps providers feel it's necessary because not all of them require transactions with a billing/mailing address all the time (think free/trial services or gift cards)? One can only attempt to conceive of the inconceivable...
Re: Question about normal ops - BGP Flaps nightly
On Thu, 21 Nov 2019 at 19:44, Baldur Norddahl wrote: > A BGP reset can cause routing trouble for as much as 15 minutes. Since you > have two sessions that mitigates the problem somewhat. But nevertheless this > will not be acceptable. As there are best path algorithms which consider route age, BGP reset impact may be indefinite. -- ++ytti
Re: Question about normal ops - BGP Flaps nightly
A BGP reset can cause routing trouble for as much as 15 minutes. Since you have two sessions that mitigates the problem somewhat. But nevertheless this will not be acceptable. Regards Baldur tor. 21. nov. 2019 10.47 skrev Christopher Morrow : > Howdy! > A question of interest to me, currently, is whether it's normal for > providers to cause BGP flaps to their customers nightly... This seems, > in my case, to be the provider PROBABLY updating prefix-filters on my > session(s). > > Particularly AS56554 is currently getting v4/v6 transit from 2 > providers, one of which we have 2 links toward. That provider appears > to flap both of our ipv6 (only) bgp peers each night at about the same > time each night. This smells like: "filter updates', but something > that's different than the v4 filter update? (or perhaps they have no > v4 filtering to update?) > > In the end, should customers expect nightly (or on a regular cadence) > to see their sessions bounce? It hasn't been my experience in other > situations... > > -chris >
Re: Question about normal ops - BGP Flaps nightly
I agree that this sounds like an automated process in some way. I would suspect that either a vendor code update changed something such that a given command that would not cause session reset now does, or they changed their automation to include a command that would cause a reset without realizing it/slipped through the cracks / etc. On Thu, Nov 21, 2019 at 9:18 AM Mel Beckman wrote: > No. There should be no reason to bounce the session. Do you have soft > updates turn on? > > -mel via cell > > > On Nov 21, 2019, at 1:46 AM, Christopher Morrow > wrote: > > > > Howdy! > > A question of interest to me, currently, is whether it's normal for > > providers to cause BGP flaps to their customers nightly... This seems, > > in my case, to be the provider PROBABLY updating prefix-filters on my > > session(s). > > > > Particularly AS56554 is currently getting v4/v6 transit from 2 > > providers, one of which we have 2 links toward. That provider appears > > to flap both of our ipv6 (only) bgp peers each night at about the same > > time each night. This smells like: "filter updates', but something > > that's different than the v4 filter update? (or perhaps they have no > > v4 filtering to update?) > > > > In the end, should customers expect nightly (or on a regular cadence) > > to see their sessions bounce? It hasn't been my experience in other > > situations... > > > > -chris >
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
> > If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to > the US and watch them on my laptop, no-one is screaming that I'm violating > someone's geographic distribution rights by doing so. If a US citizen is > paying for Hulu, from a US billing address, on a US credit card, but > happens to be watching from their hotel in Italy, why does anyone care? > Hulu probably doesn't. But many content owners are still riding that Region Locking Hype Train in the face of all the available evidence that it doesn't really do anything but create a nuisance. And they do pretty much have you over the barrel, since you likely don't have another option. On Thu, Nov 21, 2019 at 5:34 AM t...@pelican.org wrote: > On Wednesday, 20 November, 2019 21:25, "William Herrin" > said: > > > This is why you don't go after Hulu. You go after the content owners who > > conspired to compel Hulu to limit distribution in a way that tortiously > > interferes with your contract with your eyeball customers. > > Am I the only one who's baffled in the context of a paid service why so > much focus is put on where the consumption takes place (hard), and so > little on where the transaction take place (easy)? > > I understand, even if I don't necessarily always agree with, market > segmentation, differentiated pricing, accurate P for different business > units, etc, that mean for example if you're a US citizen you need to pay > Disney US the prevailing US price to watch Disney content, but if you're an > EU citizen you need to pay Disney EMEA the prevailing EU price to watch > Disney content. Surely that transaction is the thing content creators and > distributors care about? > > If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to > the US and watch them on my laptop, no-one is screaming that I'm violating > someone's geographic distribution rights by doing so. If a US citizen is > paying for Hulu, from a US billing address, on a US credit card, but > happens to be watching from their hotel in Italy, why does anyone care? > > I can see why it's different and more complicated for content that's > provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation > for paid services seems a terrible waste of time and effort on both sides. > > Or am I woefully naive, and it's actually trivial for a non-US resident to > come up with a US credit card and billing address to pay for the service? > > Regards, > Tim. > > >
Re: Fastly Peering Contact
https://twitter.com/ryan505/status/1196499414443077638 ^^ For anyone who's needing urgency, feel free to reach out to me directly. We're working on some automation on this front, but in the meantime... On Thu, Nov 21, 2019 at 8:19 AM Ryan Landry wrote: > Hi Chad! I'll follow up on this with you directly. > > Ryan @ Fastly > > On Thu, Nov 21, 2019 at 8:16 AM Chad Sorrell < > csorr...@intelligentfiber.com> wrote: > >> Anyone have a contact at Fastly they could send me offline? I’ve been >> trying to get something established since March and I haven’t heard >> anything at all. I’m concerned maybe my email isn’t reaching anyone. >> >> >> >> Thanks >> >> >> >> -- >> >> Chad Sorrell >> >> Network Architect >> >> Intelligent Fiber Network >> >> >> >
Re: Fastly Peering Contact
Hi Chad! I'll follow up on this with you directly. Ryan @ Fastly On Thu, Nov 21, 2019 at 8:16 AM Chad Sorrell wrote: > Anyone have a contact at Fastly they could send me offline? I’ve been > trying to get something established since March and I haven’t heard > anything at all. I’m concerned maybe my email isn’t reaching anyone. > > > > Thanks > > > > -- > > Chad Sorrell > > Network Architect > > Intelligent Fiber Network > > >
Fastly Peering Contact
Anyone have a contact at Fastly they could send me offline? I've been trying to get something established since March and I haven't heard anything at all. I'm concerned maybe my email isn't reaching anyone. Thanks -- Chad Sorrell Network Architect Intelligent Fiber Network
Re: Question about normal ops - BGP Flaps nightly
No. There should be no reason to bounce the session. Do you have soft updates turn on? -mel via cell > On Nov 21, 2019, at 1:46 AM, Christopher Morrow > wrote: > > Howdy! > A question of interest to me, currently, is whether it's normal for > providers to cause BGP flaps to their customers nightly... This seems, > in my case, to be the provider PROBABLY updating prefix-filters on my > session(s). > > Particularly AS56554 is currently getting v4/v6 transit from 2 > providers, one of which we have 2 links toward. That provider appears > to flap both of our ipv6 (only) bgp peers each night at about the same > time each night. This smells like: "filter updates', but something > that's different than the v4 filter update? (or perhaps they have no > v4 filtering to update?) > > In the end, should customers expect nightly (or on a regular cadence) > to see their sessions bounce? It hasn't been my experience in other > situations... > > -chris
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
On Thursday, 21 November, 2019 12:00, "Rob Seastrom" said: >> On Nov 21, 2019, at 05:33, "t...@pelican.org" wrote: >> >> Or am I woefully naive, and it's actually trivial for a non-US resident to >> come >> up with a US credit card and billing address to pay for the service? > > It’s a thing. Need a US address but fairly straightforward. Ask your > favorite border hopping Canadian. > Fair enough - thanks for the info. These days, you have to show up in person at a branch with a passport to open almost any kind of bank account here, following a money-laundering crackdown, so I was assuming it ought to be a sufficiently-strong check to satisfy rights-holders. Regards, Tim.
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
On Wednesday, 20 November, 2019 21:25, "William Herrin" said: > This is why you don't go after Hulu. You go after the content owners who > conspired to compel Hulu to limit distribution in a way that tortiously > interferes with your contract with your eyeball customers. Am I the only one who's baffled in the context of a paid service why so much focus is put on where the consumption takes place (hard), and so little on where the transaction take place (easy)? I understand, even if I don't necessarily always agree with, market segmentation, differentiated pricing, accurate P for different business units, etc, that mean for example if you're a US citizen you need to pay Disney US the prevailing US price to watch Disney content, but if you're an EU citizen you need to pay Disney EMEA the prevailing EU price to watch Disney content. Surely that transaction is the thing content creators and distributors care about? If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so. If a US citizen is paying for Hulu, from a US billing address, on a US credit card, but happens to be watching from their hotel in Italy, why does anyone care? I can see why it's different and more complicated for content that's provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation for paid services seems a terrible waste of time and effort on both sides. Or am I woefully naive, and it's actually trivial for a non-US resident to come up with a US credit card and billing address to pay for the service? Regards, Tim.
Re: Question about normal ops - BGP Flaps nightly
On Thu, Nov 21, 2019 at 4:48 AM Jared Mauch wrote: > > > > > On Nov 21, 2019, at 4:45 AM, Christopher Morrow > > wrote: > > > > Howdy! > > A question of interest to me, currently, is whether it's normal for > > providers to cause BGP flaps to their customers nightly... This seems, > > in my case, to be the provider PROBABLY updating prefix-filters on my > > session(s). > > > > Particularly AS56554 is currently getting v4/v6 transit from 2 > > providers, one of which we have 2 links toward. That provider appears > > to flap both of our ipv6 (only) bgp peers each night at about the same > > time each night. This smells like: "filter updates', but something > > that's different than the v4 filter update? (or perhaps they have no > > v4 filtering to update?) > > > > In the end, should customers expect nightly (or on a regular cadence) > > to see their sessions bounce? It hasn't been my experience in other > > situations... > > > This seems unusual, perhaps a bug in their tooling or their config where it’s > doing a hard clear vs soft clear on the session? This was sort of my thinking, but I was unsure if there was some new process and/or bug which other edge-y folk were dealing with of late. I can/will ask the provider in question (a local apac provider) if they are aware of the actions they are taking.
Re: Question about normal ops - BGP Flaps nightly
> On Nov 21, 2019, at 4:45 AM, Christopher Morrow > wrote: > > Howdy! > A question of interest to me, currently, is whether it's normal for > providers to cause BGP flaps to their customers nightly... This seems, > in my case, to be the provider PROBABLY updating prefix-filters on my > session(s). > > Particularly AS56554 is currently getting v4/v6 transit from 2 > providers, one of which we have 2 links toward. That provider appears > to flap both of our ipv6 (only) bgp peers each night at about the same > time each night. This smells like: "filter updates', but something > that's different than the v4 filter update? (or perhaps they have no > v4 filtering to update?) > > In the end, should customers expect nightly (or on a regular cadence) > to see their sessions bounce? It hasn't been my experience in other > situations... This seems unusual, perhaps a bug in their tooling or their config where it’s doing a hard clear vs soft clear on the session? - Jared
Question about normal ops - BGP Flaps nightly
Howdy! A question of interest to me, currently, is whether it's normal for providers to cause BGP flaps to their customers nightly... This seems, in my case, to be the provider PROBABLY updating prefix-filters on my session(s). Particularly AS56554 is currently getting v4/v6 transit from 2 providers, one of which we have 2 links toward. That provider appears to flap both of our ipv6 (only) bgp peers each night at about the same time each night. This smells like: "filter updates', but something that's different than the v4 filter update? (or perhaps they have no v4 filtering to update?) In the end, should customers expect nightly (or on a regular cadence) to see their sessions bounce? It hasn't been my experience in other situations... -chris
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
> On Nov 20, 2019, at 12:44 , Brandon Martin wrote: > > On 11/20/19 3:31 PM, Owen DeLong wrote: >> As an ISP, there might be something there, but, you’d have to prove that you >> had a significant number of customers that left for that specific reason and >> you’d have to show the actual damages that resulted. Easy to estimate, very >> hard to prove. > > Not only hard to prove, but the armchair lawyer in my has an inkling that > you'd have to show that they did it intentionally or went beyond being dumb > or knowledgeable about it and were somehow negligent. The former seems even > more difficult than proving actual damages, and the latter seems like it may > not even apply or be possible. Correct me if I’m wrong, but being dumb about it _IS_ negligent, isn’t it? > What irks me most about these situations as an operator, and indeed something > that may push back on my previous statement of intent or negligence not being > possible/applicable, is that the services often make their geofencing/IP > classification system failures out as being the fault of the user's > telecommunications service provider when, in fact, the user's service > provider often has absolutely no direct control over what happens and, even > where they do have some form of direct control such as through a documented > operations-appeals channel, are still at the mercy of the service doing the > fencing/classification to correct the error. At minimum, this could damage > customer good will toward their service provider. Yep… Hence what I proposed as regulation to help curtail this BS. > (And kudos where it's due to the providers who do NOT make such issues appear > to be the fault of the user's telecommunications service provider and instead > provide a real, useful means for the user to directly contact the content > provider to resolve the issue) Who are they? I want to shift my services to them if I can. (So far, I haven’t found any) Owen
