Re: Power outages Maryland near Washington DC (Plane crash into power lines)
Here’s a pilot’s-perspective report of the crash and amazing rescue, with more pics: https://us4.campaign-archive.com/?e=582d83d772=1a3819bbb44ebf8f1e02946a0=59eeed292b -mel beckman On Nov 27, 2022, at 5:40 PM, Sean Donelan wrote: A small plane crashed into high-voltage transmission power lines in Montgomery County, Maryland; near Washington DC. Most of the data centers are in Northern Virginia, but some are in Southern Maryland (Wheaton, Olney, Gaithersburg and as far away as Silver Spring). https://wtop.com/montgomery-county/2022/11/outages-in-montgomery-co-after-small-plane-crashes-into-power-lines/
Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC
Dear Mr. Beecher: 0) Thanks for your reply to close the loop. 1) " I don't have any interest in continuing this discussion on this topic.": I am quite surprised by your nearly 180 degree turn of your position from your last MSG. The only thing that I could think of is that my last MSG provided the missing information that made the difference. I would appreciate very much if you could confirm. Regards, Abe (2022-12-02 22:35 EST) On 2022-12-01 16:34, Tom Beecher wrote: Mr. Chen- I don't have any interest in continuing this discussion on this topic. Best of luck to you. On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen wrote: Dear Tom: Have not heard from you since the below MSG. Could you please let me know if you have seen it, so that we can carry on by avoiding the repeated open-loop situation with this thread? Regards, Abe (2022-12-01 07:44 EST) On 2022-11-22 23:23, Abraham Y. Chen wrote: > Dear Tom: Please disregard an earlier partial transmission of > this MSG, caused by operator error. *** > > 1) One look at the NANOG archive that you retrieved tells me that we > are the victims of the idiosyncrasies of the eMail system. Unlike > snail mails that are slow but reliable (There was a story that USPS > found a forty years old letter stuck in one of the mail collection > boxes on Boston sidewalk and then delivered it.), eMails are fast > (Once my eMail monitoring account started to receive a long message > that I was sending out, even before it was fully sent.) but > unpredictable from time to time. Unfortunately, most of us are > conditioned with its daily behavior and do not suspect the electronic > system hiccups (As Andrew Grove once said, "It is the software, not > the hardware."). To deal with this kind of issues in none-real-time > communications, I practice a discipline, started from VM and FAX, that > I will do my best to respond within 24 hours. I encourage my > colleagues to start reminding me (either repeat the MSG or using > alternative channels, such as SkyPe - My handle is "Abraham.Y.Chen"), > if they do not hear from me after 48 hours on topics that they expect > my response. This convention prevented much of the disruptions. > Looking at your comments, I definitely would have responded back then > if I saw them. One possibility is that I was in the midst of being > overwhelmed by NANOG posting protocols, such as the digest mode, > uni-code, personal writing styles, etc. and miseed your MSG. Anyway, > allow me to try carrying on. > > 2) "...Your proposal appears to rely on a specific value in the IP > option header to create your overlay": Not really, as soon as the > 100.64/10 netblock is replaced by the 240/4, each CG-NAT module can > serve a very large area (such as Tokyo Metro and such) that becomes > the RAN in EzIP terminology. Since each RAN is tethered from the > existing Internet core by an umbilical cord operating on one IPv4 > public address, this is like a kite floating in the sky which is the > basic building block for the overlaying EzIP Sub-Internet when they > expand wide enough to begin covering significant areas of the world. > Note that throughout this entire process, the Option Word mechanism in > the IP header does not need be used at all. (It turns out that > utilizing the CG-NAT configuration as the EzIP deployment vehicle, the > only time that the Option Word may be used is when subscribers in two > separate RANs wishing to have end-to-end communication, such as direct > private eMail exchanges.) > > 3) " ... to drop any packet with an IP option set that you don't > explicitly want because a significant number of routers kick every > packet with options to CPU, ... ": Yes, this was what we were reminded > of when we started our study. However, this appears to be another > Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's > Refernce 13) told me that his team had successfully sent packets with > Option Words. Again, even if the existing routers do knock out packs > with Option words, the overlay architecture of the RANs allows the > search for those do allow this operation. Since the use of the Option > Word turns out to be an option to superceed IPv4's capabilities, we > should treat it as a consideration for future premium services. > > 4) " ...Any device that still treated 240/4 differently would need to > be updated to treat it like anything else. .. ": Yes, this applies to > regions that desire to enjoy the EzIP characteristics. Since the root > of each RAN (or sub-RAN) still appears to be one of the current CG-NAT > modules, there is no change can be detected
Re: Experiences with commercial NOS vendors in white box space
Hey, BCM DNX ASICs don’t make a device a white-box, many commercial vendors programming it either completely or at least partially avoiding using BCM SDK, using DB’s in different ways, etc. Looking at a choice of modern NOSes, Arrcus is a high performance,YANG programmable vertically integrated NOS built specifically (own HAL) on DNX. OcNOS - haven’t touched it for a couple of years, never liked it (for aforementioned reasons and more). RtBrick - another modern, highly scalable NOS using DNX, that also provides fully fledges BRAS. I’ll CC CTOs of both companies so you could contact them p2p. Hope this is helpful. Cheers, Jeff > On Nov 30, 2022, at 07:51, Graham Johnston wrote: > > Good day. > > I'm curious to hear from those with direct, hopefully in-production, > experience in using a commercial network operating system vendor along > with white box switches. I'm specifically looking for operators in the > service provider space, rather than data center or enterprise. I'm > largely focused on Jericho2/Qumran2 based devices, with what would > likely be modest feature requirements. We currently use MPLS with RSVP > to build automatic paths, but don't do anything specific for traffic > engineering. Segment routing isn't a requirement for today. Currently > use more traditional forms of MPLS services for customer L2 and L3 > VPNs, but are investigating a transition to EVPN. Automation is very > much important to us, as are routing security features. Based on > research, and use of vertically integrated Jericho-based switches, we > aren't concerned about QoS as our needs aren't super complex. I guess > I'm largely saying that we don't expect the ASIC to be the weak point > in our use case, but rather the NOS or the nature of support from the > vendor. > > I'm aware of IPInfusion and their OcNOS product, but the CLI and > config syntax feels dated. I feel like I've been ruined by Cisco RPL, > Juniper policy-statements, and Arista RCF and expect I would find > wanting more than what route-map syntax has to offer. Can I accomplish > the same complex routing policies via route-maps that I can with more > modern solutions, and I'm just assuming it's limiting? Is it fair to > say that even if I can achieve the same functionality, that route-maps > are the poorer choice when it comes to the human interaction aspect? > > I know of Arrcus, but don't know much more than I can see on their > website. Edge-core has an interesting reference in its Open Networking > Solution Guide on their website in which they position Arrcus for core > applications and IPInfusion for access and aggregation. All of which > could be meaningless based on the varied definitions and expectations > of what a core network is and does. Is it feature rich or just a set > of fast LSR P-routers? The Edge-Cor guide also identifies Exaware and > Capgemini, both of whom I know little about. Are there viable SP > focused NOS vendors that I haven't touched on? > > Thanks in advance for any reply, be it on-list or off-list. > > Regards, > Graham
Weekly Global IPv4 Routing Table Report
This is an automated weekly mailing describing the state of the Global IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net. For historical data, please see https://thyme.apnic.net. If you have any comments please contact Philip Smith . IPv4 Routing Table Report 04:00 +10GMT Sat 03 Dec, 2022 BGP Table (Global) as seen in Japan. Report Website: https://thyme.apnic.net Detailed Analysis: https://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 916495 Prefixes after maximum aggregation (per Origin AS): 346331 Deaggregation factor: 2.65 Unique aggregates announced (without unneeded subnets): 443280 Total ASes present in the Internet Routing Table: 73865 Prefixes per ASN: 12.41 Origin-only ASes present in the Internet Routing Table: 63445 Origin ASes announcing only one prefix: 26042 Transit ASes present in the Internet Routing Table: 10420 Transit-only ASes present in the Internet Routing Table:416 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 55 Max AS path prepend of ASN (265020) 50 Prefixes from unregistered ASNs in the Routing Table: 1005 Number of instances of unregistered ASNs: 1010 Number of 32-bit ASNs allocated by the RIRs: 40761 Number of 32-bit ASNs visible in the Routing Table: 33760 Prefixes from 32-bit ASNs in the Routing Table: 164587 Number of bogon 32-bit ASNs visible in the Routing Table:16 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:526 Number of addresses announced to Internet: 3063369856 Equivalent to 182 /8s, 151 /16s and 80 /24s Percentage of available address space announced: 82.7 Percentage of allocated address space announced: 82.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.6 Total number of prefixes smaller than registry allocations: 311275 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 239683 Total APNIC prefixes after maximum aggregation: 68244 APNIC Deaggregation factor:3.51 Prefixes being announced from the APNIC address blocks: 234521 Unique aggregates announced from the APNIC address blocks:97382 APNIC Region origin ASes present in the Internet Routing Table: 13128 APNIC Prefixes per ASN: 17.86 APNIC Region origin ASes announcing only one prefix: 3821 APNIC Region transit ASes present in the Internet Routing Table: 1756 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 31 Number of APNIC region 32-bit ASNs visible in the Routing Table: 8383 Number of APNIC addresses announced to Internet: 773709312 Equivalent to 46 /8s, 29 /16s and 222 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-151865 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:267297 Total ARIN prefixes after maximum aggregation: 121921 ARIN Deaggregation factor: 2.19 Prefixes being announced from the ARIN address blocks: 268818 Unique aggregates announced from the ARIN address blocks:129483 ARIN Region origin ASes present in the Internet Routing Table:19070 ARIN Prefixes per ASN:
