FCC and CISA host roundtable on Alerting Security Oct 30 2023
The Federal Communications Commission’s Public Safety and Homeland Security Bureau (PSHSB), together with the Cybersecurity and Infrastructure Security Agency (CISA)’s Emergency Communications Division, will host a public roundtable on the cybersecurity of the nation’s public alert and warning systems. The roundtable will start at 9:30 a.m. EDT on Monday, October 30, 2023. This event will focus on cybersecurity in alerting, risk management frameworks as well as the cost and benefits of implementing these in incident reporting for alerting. https://www.fcc.gov/document/fcc-and-cisa-host-alerting-security-roundtable-oct-30
Re: transit and peering costs projections
The issue in Houston is Dallas. I reached out to 30-40 networks and 90% of them all said they just back haul to Dallas and have no interest in peering in Houston. It’s a real hard town to get any traction in. If you’re local and have some insight, I’d be super happy to talk to you. Aaron > On Oct 14, 2023, at 8:48 PM, Tim Burke wrote: > > I would say that a 1Gbit IP transit in a carrier neutral DC can be had for a > good bit less than $900 on the wholesale market. > > Sadly, IXP’s are seemingly turning into a pay to play game, with rates almost > costing as much as transit in many cases after you factor in loop costs. > > For example, in the Houston market (one of the largest and fastest growing > regions in the US!), we do not have a major IX, so to get up to Dallas it’s > several thousand for a 100g wave, plus several thousand for a 100g port on > one of those major IXes. Or, a better option, we can get a 100g flat internet > transit for just a little bit more. > > Fortunately, for us as an eyeball network, there are a good number of major > content networks that are allowing for private peering in markets like > Houston for just the cost of a cross connect and a QSFP if you’re in the > right DC, with Google and some others being the outliers. > > So for now, we'll keep paying for transit to get to the others (since it’s > about as much as transporting IXP from Dallas), and hoping someone at Google > finally sees Houston as more than a third rate city hanging off of Dallas. > Or… someone finally brings a worthwhile IX to Houston that gets us more than > peering to Kansas City. Yeah, I think the former is more likely. > > See y’all in San Diego this week, > Tim > >> On Oct 14, 2023, at 18:04, Dave Taht wrote: >> >> This set of trendlines was very interesting. Unfortunately the data >> stops in 2015. Does anyone have more recent data? >> >> https://drpeering.net/white-papers/Internet-Transit-Pricing-Historical-And-Projected.php >> >> I believe a gbit circuit that an ISP can resell still runs at about >> $900 - $1.4k (?) in the usa? How about elsewhere? >> >> ... >> >> I am under the impression that many IXPs remain very successful, >> states without them suffer, and I also find the concept of doing micro >> IXPs at the city level, appealing, and now achievable with cheap gear. >> Finer grained cross connects between telco and ISP and IXP would lower >> latencies across town quite hugely... >> >> PS I hear ARIN is planning on dropping the price for, and bundling 3 >> BGP AS numbers at a time, as of the end of this year, also. >> >> >> >> -- >> Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html >> Dave Täht CSO, LibreQos
Re: jon postel
Jon was very kind to me when I was a wet-behind-the-ears network engineer. He once showed me around ISI and gave me an entire shelf of down-version Cisco manuals. I had a Cisco 2500 peering with ISI in a maintenance closet in the ISI parking structure. A single T1 let me run a few dozen Livingston modems for my nascent Jet.net ISP. -mel On Oct 16, 2023, at 2:44 PM, Collider wrote: is it candle time? Le 16 octobre 2023 21:13:50 UTC, Randy Bush a écrit : 25 years ago, jon postel died. we stand on the shoulders of jon and others, a number of whom died in october. not a cheering month for old timers. randy -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
RE: Add communities on direct routes in Juniper
Junos doesn't maintain an intermediate BGP table / RIB as you would see on other Cisco-like platforms. Therefore you need to build comm-string actions into your neighborship policies.
RE: MX204 tunnel services BW
JTAC says we must disable a physical port to allocate BW for tunnel-services. Also leaving tunnel-services bandwidth unspecified is not possible on the 204. I haven't independently tested / validated in lab yet, but this is what they have told me. I advised JTAC to update the MX204 "port-checker" tool with a tunnel-services knob to make this caveat more apparent.
Re: jon postel
is it candle time? Le 16 octobre 2023 21:13:50 UTC, Randy Bush a écrit : >25 years ago, jon postel died. we stand on the shoulders of jon and >others, a number of whom died in october. not a cheering month for >old timers. > >randy -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
jon postel
25 years ago, jon postel died. we stand on the shoulders of jon and others, a number of whom died in october. not a cheering month for old timers. randy
Re: MX204 tunnel services BW
Looks like the MX204 Is a bit of an odd duck in the MX series. It probably shares some hardware characteristics under the hood (even the MX80 (mostly, there was a variant that had pre-installed interfaces) had MIC slots). The MX-204 appears to be an entirely fixed configuration chassis and looks from the literature like it is based on pre-trio chipset technology. Interesting that there are 100Gbe interfaces implemented with this seemingly older technology, but yes, looks like the PFE on the MX-204 has all the same restrictions as a DPC-based line card in other MX-series routers. Owen > On Oct 16, 2023, at 12:49, Jeff Behrns via NANOG wrote: > > JTAC says we must disable a physical port to allocate BW for tunnel-services. > Also leaving tunnel-services bandwidth unspecified is not possible on the > 204. I haven't independently tested / validated in lab yet, but this is what > they have told me. I advised JTAC to update the MX204 "port-checker" tool > with a tunnel-services knob to make this caveat more apparent. >
Re: transit and peering costs projections
On 10/15/23 8:33 PM, Matthew Petach wrote: I think we often forget just how much of a massive inversion the communications industry has undergone; back in the 80s, when I started working in networking, everything was DS0 voice channels, and data was just a strange side business that nobody in the telcos really understood or wanted to sell to. At the time, the volume of money being raked in from those DS0/VGE channels was mammoth compared to the data networking side; we weren't even a rounding error. But as the roles reversed and the pyramid inverted, the data networking costs didn't rise to meet the voice costs (no matter how hard the telcos tried to push VGE-mileage-based pricing models! Haha, when I was at Cisco in the late 90's and was working on VoIP stuff we were working with Sprint trying to get them onboard for a residential voice project. They were really insistent on using AAL2 to conserve bandwidth. I told them at the time that the bandwidth for voice was going to be insignificant and it wasn't a big deal that RTP wasn't as efficient. They looked at me like i had leprosy with body parts falling off. Like the next month it was announced that data had surpassed voice for the first time. We didn't get the contract, fwiw. But they never launched anything either. Was there ever any significant deployment of AAL2? Mike
Re: jon postel
> I wonder if he knew it would have become what it is today. one of my favorite postel quotes It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. think of the folk making careers complicating dns, rpki, bgp, ... randy
Re: jon postel
I wasn’t even born yet when he died, but as humans we are lucky to have had someone like him, along with a great many other folks along side him. One of my professors at Michigan (his name eludes me for some reason) always had a great many stories about him and other folks in that time period, must have been a crazy thing to watch unfold in real time. I wonder if he knew it would have become what it is today. > On Oct 16, 2023, at 17:13, Randy Bush wrote: > > 25 years ago, jon postel died. we stand on the shoulders of jon and > others, a number of whom died in october. not a cheering month for > old timers. > > randy
Re: MX204 tunnel services BW
On Mon, 16 Oct 2023 at 22:49, wrote: > JTAC says we must disable a physical port to allocate BW for tunnel-services. > Also leaving tunnel-services bandwidth unspecified is not possible on the > 204. I haven't independently tested / validated in lab yet, but this is what > they have told me. I advised JTAC to update the MX204 "port-checker" tool > with a tunnel-services knob to make this caveat more apparent. Did they explain why you need to disable the physical port? I'd love to hear that explanation. The MX204 is single Trio EA, so you can't even waste serdes sending the packet to remote PFE after first lookup, it would only bounce between local XM/MQ and LU/XL, wasting that serdes. -- ++ytti
Re: MX204 tunnel services BW
On 10/17/23 03:20, Ryan Kozak wrote: "The MX204 router supports two inline tunnels - one per PIC. To configure the tunnel interfaces, include the tunnel-services statement and an optional bandwidth of 1 Gbps through 200 Gbps at the \[edit chassis fpc fpc-slot pic number\] hierarchy level. If you do not specify the tunnel bandwidth then, the tunnel interface can have a maximum bandwidth of up to 200 Gbps." If JTAC is saying it's no longer optional they need to update their docs. We can commit "tunnel-services" on an MX204 without caveat. Mark.
Re: MX204 tunnel services BW
On Tue, 17 Oct 2023 at 00:28, Delong.com wrote: > The MX-204 appears to be an entirely fixed configuration chassis and looks > from the literature like it is based on pre-trio chipset technology. > Interesting that there are 100Gbe interfaces implemented with this seemingly > older technology, but yes, looks like the PFE on the MX-204 has all the same > restrictions as a DPC-based line card in other MX-series routers. It is 100% normal Trio EA. -- ++ytti
Re: MX204 tunnel services BW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 According to: [https://www.juniper.net/documentation/us/en/software/junos/interfaces-encryption/topics/topic-map/configuring-tunnel-interfaces.html\#id-configuring-tunnel-interfaces-on-mx-204-routers][https_www.juniper.net_documentation_us_en_software_junos_interfaces-encryption_topics_topic-map_configuring-tunnel-interfaces.html_id-configuring-tunnel-interfaces-on-mx-204-routers] "The MX204 router supports two inline tunnels - one per PIC. To configure the tunnel interfaces, include the tunnel-services statement and an optional bandwidth of 1 Gbps through 200 Gbps at the \[edit chassis fpc fpc-slot pic number\] hierarchy level. If you do not specify the tunnel bandwidth then, the tunnel interface can have a maximum bandwidth of up to 200 Gbps." If JTAC is saying it's no longer optional they need to update their docs. AFAIK, tunnel services doesn't directly take bandwidth from physical ports, but it does take from the total available PFE bandwidth. Disabling a port may be required as the MX204 has a maximum PFE bandwidth of 400G and you can oversubscribe that with the fixed physical ports. I just checked a production config as an example, note how et-0/0/3 is not configured so the total bandwidth adds up to 400g: set chassis fpc 0 pic 0 tunnel-services bandwidth 20g set chassis fpc 0 pic 0 port 0 speed 100g set chassis fpc 0 pic 0 port 1 speed 100g set chassis fpc 0 pic 0 port 2 speed 100g set chassis fpc 0 pic 1 port 0 speed 10g set chassis fpc 0 pic 1 port 1 speed 10g set chassis fpc 0 pic 1 port 2 speed 10g set chassis fpc 0 pic 1 port 3 speed 10g set chassis fpc 0 pic 1 port 4 speed 10g set chassis fpc 0 pic 1 port 5 speed 10g set chassis fpc 0 pic 1 port 6 speed 10g set chassis fpc 0 pic 1 port 7 speed 10g Regards, Ryan \ Original Message On Oct. 16, 2023, 12:49, Jeff Behrns via NANOG < nanog@nanog.org> wrote: > > JTAC says we must disable a physical port to allocate BW for tunnel-services. > Also leaving tunnel-services bandwidth unspecified is not possible on the > 204. I haven't independently tested / validated in lab yet, but this is what > they have told me. I advised JTAC to update the MX204 "port-checker" tool > with a tunnel-services knob to make this caveat more apparent. [https_www.juniper.net_documentation_us_en_software_junos_interfaces-encryption_topics_topic-map_configuring-tunnel-interfaces.html_id-configuring-tunnel-interfaces-on-mx-204-routers]: https://www.juniper.net/documentation/us/en/software/junos/interfaces-encryption/topics/topic-map/configuring-tunnel-interfaces.html#id-configuring-tunnel-interfaces-on-mx-204-routers -BEGIN PGP SIGNATURE- Version: ProtonMail wnUEARYIACcFAmUt4VMJEP7aH/V1zBsBFiEExqGOs9CyQpg6/JJ5/tof9XXM GwEAAJF0AQCDM0b/X+LFPSXjVfC6NQGEyszqkIkbq84tmzl+boOJgwD+NM8u n7o4e2SoCYs8yOIyaii2ElG+SFT735zXQhFx6A4= =JuZc -END PGP SIGNATURE- publickey - EmailAddress(s=ryan@kozak.io) - 0xC6A18EB3.asc Description: application/pgp-keys publickey - EmailAddress(s=ryan@kozak.io) - 0xC6A18EB3.asc.sig Description: PGP signature
Re: MX204 tunnel services BW
On 10/16/23 21:49, Jeff Behrns via NANOG wrote: Also leaving tunnel-services bandwidth unspecified is not possible on the 204. This is true of other MX platforms as well, unless I misunderstand. Mark.
