Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps
Comcast still has data caps. My service is 1.2 TB per month. If we get close, we get a warning email. If we were to go over (hasn’t happened yet), we get billed per additional 500 MB. However, I just looked at my account usage for the first time for a few months, and somehow have had zero usage since March of this year. On Thu, Jun 15, 2023 at 5:48 PM Michael Thomas wrote: > > On 6/15/23 3:19 PM, Sean Donelan wrote: > > > > While a lot of ISPs gave up on data caps, the language is still > > lurking in many Terms Of Service. > > > > > > > > > https://www.fcc.gov/document/chair-rosenworcel-proposes-investigate-impact-data-caps > > > > > > proposed Notice of Inquiry to learn more about how broadband providers > > use data caps on consumer plans. Data caps, or usage limits, are a > > common practice where an internet service provider (ISP) restricts how > > much bandwidth or data a consumer uses, though many broadband ISPs > > temporarily or permanently refrained from enforcing or imposing data > > caps in response to the COVID-19 pandemic. In particular, the agency > > would like to better understand the current state of data caps, their > > impact on consumers, and whether the Commission should consider taking > > action to ensure that data caps do not cause harm to competition or > > consumers’ ability to access > > broadband Internet services. > > So why did they back off? Cost too much in support calls with pissed > people? Bad publicity? People can't meaningfully use the offered > bandwidth these days? Something else? > > Mike > >
Re: BGP routing ARIN space in APNIC region
On Fri, 9 Jun 2023, Matthew Petach wrote: I previously wrote: Every platform I've used has a knob for turning off / relaxing as-path loop detection. Note, for some platforms (at least Juniper), you may also have to have your upstream provider "advertise-peer-as", though I suspect it's highly unlikely you'd have BGP service from the same upstream in both CA and PH...so this won't likely be an issue. I'd recommend this be treated as a "BGP 201" level exercise, not a "BGP 101" knob to turn. If you're asking for advice from the NANOG mailing list about how to best set up your first "remote" network location, you're in BGP 101 territory, and probably shouldn't be disabling as-path loop detection as a general rule. ^_^; No knock on you, just that it's probably best not to do that until you're a lot more comfortable with the potential gotchas that can result from making changes to the default BGP protocol behaviour on your border routers. Funny timing on this. Work somewhat recently opened a few new "island POPs", each with the same couple of transit providers and no backbone. While looking into something else, I realized one of our transits is not advertising any of these sites' routes to the other sites. MAC address lookup suggests they're running Cisco gear. Googling suggests that IOS XR has added the functionality I thought was unique to Juniper of not advertising routes to an eBGP neighbor if those routes were received from the neighbor's ASN. Juniper at least had the good sense to make this behavior configurable down to the individual neighbor. IOS XR apparently only lets you turn off this behavior at the address-family level. If the provider isn't willing to make a change like this, we may have to ask APNIC for a few ASNs...and it may be time to stop the practice of using the same ASN in all our islands. -- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: New addresses for b.root-servers.net
On Thu, Jun 15, 2023 at 7:52 PM Wes Hardaker wrote: > William Herrin writes: > > At some point, somebody's going to want to do something with the old > > /24. > > You are correct that we did not state we will or will not be returning > the address block we have back to ARIN. We do not plan on returning it > for precisely the reasons you've specified. Even if we were going to, > we would certainly stop responding on it for a long time first. And > even if we returned it, I suspect that ARIN itself would consider > carefully what to do with a returned address in the critical > infrastructure block. Hi Wes, Due respect, you should have a better fleshed-out commitment to the community than, "Here today, gone tomorrow. Probably not. Maybe." Not to put words in your mouth, but try something like, "We will continue serving root DNS requests from the old address indefinitely. We will notify the community of any change in that disposition at least 1 year prior to the change and will describe, at that time, what will change." Don't say, "We'll keep it up for as long as we feel like it, but at least a year." That's crap. > TL;DR: we agree and it's covered. Say the words. THEN we agree that it's covered. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: New addresses for b.root-servers.net
William Herrin writes: Hi Bill, > I acknowledge that you'd prefer it be, "forever and a day," and > perhaps that's what the answer should be, but in all due respect the > document you cite is completely mute on the use of addresses which are > -no longer- root DNS servers. I cited the document to discuss the fact that we can not do what you suggested: > Not a bad idea, you could also put a nice warning page up informing > them that their DNS resolver is broken and not enforcing DNSSEC while > you're at it :) as this would require us to return a different answer to a query than what is in the IANA maintained root zone (IE, we'd be synthesizing address records and hoping that the querier was using a web-browser which has been tried by many companies and is heavily frowned upon. Other options like returning a special loopback address have been better appreciated [2] but this would still require returning answers that did not match the IANA distributed root zone data which we will not do. As to your other point: > At some point, somebody's going to want to do something with the old > /24. You are correct that we did not state we will or will not be returning the address block we have back to ARIN. We do not plan on returning it for precisely the reasons you've specified. Even if we were going to, we would certainly stop responding on it for a long time first. And even if we returned it, I suspect that ARIN itself would consider carefully what to do with a returned address in the critical infrastructure block. TL;DR: we agree and it's covered. -- Wes Hardaker USC/ISI
Re: New addresses for b.root-servers.net
On Thu, Jun 15, 2023 at 7:03 PM Wes Hardaker wrote: > All root server operators have made a strong commitment to only serving > the DNS root as managed by IANA [1], I'm afraid this option is off the > table. Although you could use some wiggle-ling to try and say this > principle doesn't apply to "old addresses", I would not be willing to > take that wiggle on behalf of b.root-servers.net. Hi Wes, As I recall, the statement which started the thread could be paraphrased as one of those root server operating saying, "Hey Community, we'll continue to treat the old address as still a root DNS server for a year, maybe more, but no promises." I acknowledge that you'd prefer it be, "forever and a day," and perhaps that's what the answer should be, but in all due respect the document you cite is completely mute on the use of addresses which are -no longer- root DNS servers. At some point, somebody's going to want to do something with the old /24. If they didn't, nothing would stop them from committing to continue its use as a root DNS server (in addition to the new official address) for the remaining lifetime of the b-root service. The extra configuration and extra route announcement just don't have a high enough cost not to. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: New addresses for b.root-servers.net
Nathan Ward writes: Hi Nathan, [Sorry for the delay -- this was ICANN week and I'm just getting unburied] > Do you have query rates over time for the old and new addresses since > this change in 2017? We do indeed still get traffic on the older addresses, and its not an insignificant amount and its not just priming queries either. > Even if you end up with the same answer of 12mo, data supporting it > may give comfort to the community. As my colleague Robert Story said in a separate thread, we are still serving our old address and will almost certainly continue to serve our current address long beyond the promise date we put into the announcement. Our intent is to continue serving it longer than the announced end date, but we do not offer a promise to do so. -- Wes Hardaker USC/ISI
Re: New addresses for b.root-servers.net
Matt Corallo writes: [Sorry for the delay -- this was ICANN week and I'm just getting unburied] > > Perhaps make it a false responder in the last of those 9 years so that > > anybody who is truly that far behind on their software updates gets > > enough of a spanking to stop sending you packets. You'll have problems > > repurposing the address and its subnet until folks stop sending you > > DNS query packets, even if you don't respond to them. > > Not a bad idea, you could also put a nice warning page up informing > them that their DNS resolver is broken and not enforcing DNSSEC while > you're at it :) Responding to this topic specifically: All root server operators have made a strong commitment to only serving the DNS root as managed by IANA [1], I'm afraid this option is off the table. Although you could use some wiggle-ling to try and say this principle doesn't apply to "old addresses", I would not be willing to take that wiggle on behalf of b.root-servers.net. [1] https://www.icann.org/en/system/files/files/rssac-055-07jul21-en.pdf -- Wes Hardaker USC/ISI
Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps
On 6/15/23 3:19 PM, Sean Donelan wrote: While a lot of ISPs gave up on data caps, the language is still lurking in many Terms Of Service. https://www.fcc.gov/document/chair-rosenworcel-proposes-investigate-impact-data-caps proposed Notice of Inquiry to learn more about how broadband providers use data caps on consumer plans. Data caps, or usage limits, are a common practice where an internet service provider (ISP) restricts how much bandwidth or data a consumer uses, though many broadband ISPs temporarily or permanently refrained from enforcing or imposing data caps in response to the COVID-19 pandemic. In particular, the agency would like to better understand the current state of data caps, their impact on consumers, and whether the Commission should consider taking action to ensure that data caps do not cause harm to competition or consumers’ ability to access broadband Internet services. So why did they back off? Cost too much in support calls with pissed people? Bad publicity? People can't meaningfully use the offered bandwidth these days? Something else? Mike
FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps
While a lot of ISPs gave up on data caps, the language is still lurking in many Terms Of Service. https://www.fcc.gov/document/chair-rosenworcel-proposes-investigate-impact-data-caps proposed Notice of Inquiry to learn more about how broadband providers use data caps on consumer plans. Data caps, or usage limits, are a common practice where an internet service provider (ISP) restricts how much bandwidth or data a consumer uses, though many broadband ISPs temporarily or permanently refrained from enforcing or imposing data caps in response to the COVID-19 pandemic. In particular, the agency would like to better understand the current state of data caps, their impact on consumers, and whether the Commission should consider taking action to ensure that data caps do not cause harm to competition or consumers’ ability to access broadband Internet services.
Re: Software to document fiber networks - in house only
we use IQGeo Network Manager tool called Fiber Inventory system. Can place down fiber routes, splices, splice trays. Very neat tool. On Wed, Jun 14, 2023 at 3:26 AM Denis Fondras wrote: > Le Tue, Jun 13, 2023 at 03:12:29PM -0300, Jean Franco a écrit : > > Hi all, > > > > I know this must have been on the table before, but I'm looking for a > > in-house solution, something I can host on our own datacenter to document > > fiber networks, maps and so forth. > > > > I use a mix of Qgis, PostgreSQL, PostGIS and the GraceTHD model (which > seems to be > France specific though). This requires a bit of work at the beginning but > works > really great once installed, is self-hosted and does not require too much > attention afterwards. Qfield can be used on mobile for usage by field > technicians. >
Re: 10G CPE w/VXLAN - vendors?
On 6/15/23 09:21, Ryan Hamel wrote: It can't hold full tables for transit handoffs, but the customer can establish multi-hop BGP sessions upstream for that. Also, you don't really need to carry a full BGP table in FIB on a Metro-E router. That is one of the reasons it can remain cheap. You just need a reasonable amount of FIB slots. The ASR920 tops out at 20,000 for IPv4 and 4,000 for IPv6. That is not enough just for the IGP. The ACX7024 will do 128,000 for IPv4 and 64,000 for IPv6. That is loads better. You can restrict what BGP routes are installed into the FIB, on any modern router OS. Mark.
Re: 10G CPE w/VXLAN - vendors?
On 6/15/23 09:21, Ryan Hamel wrote: I would never let the customer manage the CPE device, unless it was through some customer portal where automation can do checks and balances, nor have the device participate in a ring topology -- home runs or bust. If the device fails or has an issue requiring a field dispatch, that is on the customer to help arrange that time and provide on-site contact info, otherwise the SLA clock stops ticking. Now if the customer refuses to allow the vendor to pickup the CPE (regardless of make/model) and/or building aggregation/demarc + UPS hardware, the police can get called for theft of equipment depending on its value, or customer/landlord is sued depending on what the contract states. Your network, your rules. As for Ciena's SAOS feature set, I was only going by the RFC's and protocols listed on some of the higher end CPE equipment. I do not have first hand experience with them. They are hoping most customers buy based on what is listed, and not what is actually tested. Sadly, enough customers do that that it still makes sense for them to market that way. From operators in my circles that have deployed optical OEM gear for MPLS, those are rapidly being swapped out for more conventional OEM's. Tier 1's as in Cogent, Level3/Lumen, Zayo, etc. Hehe... okay. Doesn't matter the size of the operation, the options for boxes is still the same. Juniper's ACX7024 does look interesting as a building demarc/agg device, but overkill for a single client CPE. It can't hold full tables for transit handoffs, but the customer can establish multi-hop BGP sessions upstream for that. Like I said, if you are looking for a CPE to participate in your Metro-E backbone, and have all the features of a PE router, that is going to be a pretty hard combination to solve. Mark.
Re: 10G CPE w/VXLAN - vendors?
I would never let the customer manage the CPE device, unless it was through some customer portal where automation can do checks and balances, nor have the device participate in a ring topology -- home runs or bust. If the device fails or has an issue requiring a field dispatch, that is on the customer to help arrange that time and provide on-site contact info, otherwise the SLA clock stops ticking. Now if the customer refuses to allow the vendor to pickup the CPE (regardless of make/model) and/or building aggregation/demarc + UPS hardware, the police can get called for theft of equipment depending on its value, or customer/landlord is sued depending on what the contract states. As for Ciena's SAOS feature set, I was only going by the RFC's and protocols listed on some of the higher end CPE equipment. I do not have first hand experience with them. Tier 1's as in Cogent, Level3/Lumen, Zayo, etc. Juniper's ACX7024 does look interesting as a building demarc/agg device, but overkill for a single client CPE. It can't hold full tables for transit handoffs, but the customer can establish multi-hop BGP sessions upstream for that. Ryan Hamel From: Mark Tinka Sent: Wednesday, June 14, 2023 11:50 PM To: Ryan Hamel ; nanog@nanog.org Subject: Re: 10G CPE w/VXLAN - vendors? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On 6/15/23 07:49, Ryan Hamel wrote: If the customer's site goes offline, that is their problem. A CPE device is still a CPE device, no matter how smart it is. Setup IS-IS, BGP to route servers, LDP + MPLS if you don't go the VXLAN route, and that's it. So you have two issues here: * If it's a pure CPE device running IS-IS, LDP, RSVP-TE, SR-MPLS, BGP, e.t.c. on the core-facing side, you have a problem if the customer can manage the router, and potentially introduces badness into your routed core. * If it's a u-PE co-located at the customer site and it goes down, you've just isolated part of your ring because, well, the customer's cleaners decided they needed the router's socket for their equipment, because it's closer than the one they usually use. As a bonus, if it's a u-PE that you need physical access to for whatever reason, but you can't because the customer does not treat their site like a typical data centre with whom you have a contract, that will be another avenue of pleasure & joy. As a bonus bonus, if it's a u-PE and you decide you are done with the site and want to decommission it, the customer can deny you entry into the site. Yes, these are real problems. Yes, these real problems have really happened. You are not my competitor, so I don't wish them upon you. I know Ciena's can do that on their more expensive 39xx models. Unless things changed, my understanding is Ciena's implementation is MPLS-TP. Does anybody know if they now have full support for IP/MPLS in the way we have it with real router vendors? There are a few tier 1's... Don't know what "teir 1's" means :-). that have delivered Ethernet transport circuits on those exact boxes in the field as I speak. It works very well. Well, the ME3600X/3800X has been EoL for quite some time now. But yes, it would work, especially if you don't run BGP on it. I also agree with your stance on Broadcom, it's hard to come up with alternatives that are not ADVA/Ciena/Cisco/RAD. So the optical OEM's are not generally good options for routers of any kind. That knocks Adva, Ciena, Infinera, Xtera, Tejas, e.t.c., off the list. Nokia do have a decent IP/MPLS platform, thanks for ALU. But the Metro-E boxes they position for that segment - the 7250 IXR-e, IXR-s and IXR-x - are also using Broadcom. Not interested in Huawei. I like Mikrotik, but only as a self-managed CPE, and not for a service provider backbone. Arrcus are currently focusing on the data centre. Arista aren't interested in the Metro-E space. HP/3Com, Dell, Extreme - very unknown quantities that I'm not motivated to look into. At the moment, the battle is really etween Cisco's NCS540 and Juniper's ACX7100/7200 platforms. Both are Broadcom-based, but I think Juniper have the slightly better idea in terms of how much they can squeeze out of Broadcom re: how much one can touch a customer's packets. Mark.
