With over a decade in service provider operations, I have led the design, optimization, and management of nationwide IP networks in Bangladesh — from rural broadband initiatives to next-generation connectivity deployments. Currently serving as Asst Manager at SSD-TECH (AS63526), my focus is on network optimization, bandwidth management, and expanding Internet access to undeserved regions.
My technical background spans IP/MPLS architecture, BGP routing, L2/L3 VPNs, and Internet Exchange (IX) peering. I am also passionate about innovation-driven deployments, including WiFi-Hat community broadband solutions, NTTN upgrades, and rural fiber expansions.
Beyond operations, I mentor field engineers, standardize troubleshooting processes, and drive cost-effective solutions to complex networking challenges. What sets me apart is the blend of industry practice and academic research: I am currently pursuing an M.Sc. in Computer Science and Engineering at North South University.
My research interests focus on advanced networking, infrastructure optimization, and rural connectivity models. This has led to global recognition:
APNIC 60 Speaker (2025): My proposal “Bangladesh_IPv6_Crisis_Myths_VS_Reality” was accepted for the Lightning Talk session. I will address key misconceptions and realities surrounding IPv6 adoption in Bangladesh.
Telecom & Digital Innovation Fair 2025 (BTRC): Selected as a Top 20 Finalist for my “Hybrid Rural Internet Solution for Bangladesh” — a solo project leveraging PTP microwave and multi-SIM LTE to bridge the digital divide. Competing alongside national operators validated my ability to innovate independently.
I am also an Active Graduate Member of IEEE (ID: 99416535), collaborating with Region 10 experts and leveraging IEEE Xplore to stay at the forefront of networking research.
When Bangladesh vanished from the global routing table in July 2024, public routing data captured the event as it unfolded. Drawing on first-hand observations from inside one affected network, this article explores what that data can and cannot tell us.
In the past two decades, the Internet in Bangladesh has gotten out from under the shadow of its earlier dependence on costly satellite links for connectivity, growing from 0.1% to over 75% penetration. But the real work lies ahead: strengthening local peering, reaching rural areas, and building inf…
“Kamruzzaman,
there’s nothing I’d push back on here. You’re right about the dump cadence, and I stand corrected: the eight-hour interval comes from the collectors’ bview schedule, while RIPEstat simply exposes it.
I also agree that treating the BDIX logs as a lower bound is the most accurate approach. Even an incomplete lower bound would help move the selective-reading argument from testimony to measurement, at least for the subset of routes that appears in the logs.
One thought on the straggler analysis: the update files should allow you to distinguish directly between the two possible readings of Signal 2. If the eight /44s were withdrawn within a few seconds of one another, and the pattern is consistent across peers, that would suggest a single cleanup action. If they disappear gradually, or coincide with a session-level event, the explanation is likely different.
That inter-arrival pattern is exactly the kind of detail that gets flattened in a RIB snapshot, so it would fit well with the timestamp labelling you already plan to add.
Send the draft over when it’s ready. I’d be very happy to read it.
--
antonio”
Antonio,
good call on the inter-arrival test. I'll check the per-peer view first. If the spread isn't consistent across peers, the timing doesn't tell me much either way.
Corrected wording goes to RIPE Labs this week. The MRT work will take a few weeks. I'll send it when it's ready.
Kamruzzaman
5 Aug, 2026
“Thanks for writing this up. Signal 2, especially the evidence around the straggler prefixes, is a rare operational detail and one of the most valuable parts of the article. A few thoughts came to mind while reading.
First, the resilience section may contain another useful signal. If the prefixes that disappeared from RIS were still being advertised or remained reachable through BDIX, that would point to a selective loss of international routing rather than a general network failure.
The BDIX traffic graph alone cannot prove this, since a failure or shutdown at the IIG or transit edge could leave domestic peering untouched. Still, the idea may be testable. If BDIX retains route-server logs or snapshots, a prefix-by-prefix comparison could show whether routes remained visible domestically while disappearing from international collectors. Bilateral sessions would not necessarily appear there, but even partial evidence would strengthen the analysis.
Second, I think the routing-security section needs a small correction. ROV enforcement at the IXP would not have made these withdrawals cryptographically auditable. RPKI validates the origin of route announcements; it does not sign or authenticate withdrawals. Even BGPsec protects the announcement path, not the later removal of a route.
A route server may of course log that a prefix disappeared, but ROV adds no cryptographic attribution to that event. The recommendation that IXPs and transit providers should state whether they enforce ROV is still a good one, but I would keep it separate from the events of 18 July.
Third, the eight-hour limitation belongs to the RIPEstat view or endpoint used in the analysis, not to RIS itself. RIS also archives the updates received by its collectors in five-minute MRT files.
The July 2024 events can therefore be reconstructed retrospectively without RIS Live and with much finer timing. This could show whether operators placed in the same eight-hour bucket actually withdrew minutes or several hours apart, and clarify how long the IPv6 stragglers remained visible. The MRT timestamp still records when an update was observed by a collector peer, not the exact moment a command was entered, but it would remove much of the ambiguity.
I would be very interested to see a follow-up based on the raw MRT data. The combination of public collector data and direct operational experience is what makes this analysis particularly valuable.
Thanks
--
antonio”
Antonio,
Thanks for this. One of the three I can close now, one I can only half close, and one you have given me a way to test.
On BDIX, the part I can settle is the alternative you raise. For AS63526 the loss of international routing originated at the AS itself — my own account as the operator, not something the collector view can show — not at an IIG or transit edge failing underneath while domestic peering stayed up. So for at least one network the selective reading holds, on operational grounds rather than on the traffic graph. What I cannot settle is which of those prefixes stayed reachable domestically at the same moment, and the section should not have rested that on the graph.
Your caveat about bilateral sessions is the binding constraint here rather than a footnote. Because a share of the peering at this exchange never touches the route servers, a prefix-by-prefix comparison would establish a lower bound on domestic visibility rather than measure it: presence in the logs is evidence, absence is not. That still helps, but it bounds how much the comparison can carry. I am asking what survives from that week, and will run the comparison if anything does.
On ROV, the distinction you draw is the one the section missed. A route server can log that a prefix disappeared, but nothing in the deployed stack attests to the disappearance. The nearest thing in progress is the Signed Prefix List work, which makes absence checkable against a declared complete set, but that is a statement about what an AS may originate rather than an authenticated record that a route was removed at a given time. RFC 8205 is explicit about this at the edge of its own threat model: withdrawal suppression is left outside the protocol and deferred to certificate rollover. So the gap is architectural rather than a matter of deployment. Agreed that the recommendation should stand apart from 18 July.
On the eight hours, one refinement: the interval is RIS's own per-collector RIB dump cadence surfaced through RIPEstat, rather than something RIPEstat introduces. Your point is unaffected, since the update files are the finer source either way, and I queried the wrong one.
Your caveat about MRT timestamps is the real limit on what the timing analysis can claim, and I would rather be explicit about it than work around it. For AS63526 I can say which withdrawals were initiated at the AS rather than inferred from the collector view, which narrows the ambiguity for one network, but that is operator testimony and not a measured offset, and I will label it as such. Where the write-up gives times, they will be collector observations, and I will say so each time rather than let the two blur.
You singled out the straggler prefixes, and that is where I will start, since it is the part I would most like to put on firmer footing.
I would value your eye on it when it is ready.
Kamruzzaman
1 Aug,2026
“Kamruzzaman, there’s nothing I’d push back on here. You’re right about the dump cadence, and I stand corrected: the eight-hour interval comes from the collectors’ bview schedule, while RIPEstat simply exposes it. I also agree that treating the BDIX logs as a lower bound is the most accurate approach. Even an incomplete lower bound would help move the selective-reading argument from testimony to measurement, at least for the subset of routes that appears in the logs. One thought on the straggler analysis: the update files should allow you to distinguish directly between the two possible readings of Signal 2. If the eight /44s were withdrawn within a few seconds of one another, and the pattern is consistent across peers, that would suggest a single cleanup action. If they disappear gradually, or coincide with a session-level event, the explanation is likely different. That inter-arrival pattern is exactly the kind of detail that gets flattened in a RIB snapshot, so it would fit well with the timestamp labelling you already plan to add. Send the draft over when it’s ready. I’d be very happy to read it. -- antonio”
Antonio, good call on the inter-arrival test. I'll check the per-peer view first. If the spread isn't consistent across peers, the timing doesn't tell me much either way. Corrected wording goes to RIPE Labs this week. The MRT work will take a few weeks. I'll send it when it's ready. Kamruzzaman 5 Aug, 2026
“Thanks for writing this up. Signal 2, especially the evidence around the straggler prefixes, is a rare operational detail and one of the most valuable parts of the article. A few thoughts came to mind while reading. First, the resilience section may contain another useful signal. If the prefixes that disappeared from RIS were still being advertised or remained reachable through BDIX, that would point to a selective loss of international routing rather than a general network failure. The BDIX traffic graph alone cannot prove this, since a failure or shutdown at the IIG or transit edge could leave domestic peering untouched. Still, the idea may be testable. If BDIX retains route-server logs or snapshots, a prefix-by-prefix comparison could show whether routes remained visible domestically while disappearing from international collectors. Bilateral sessions would not necessarily appear there, but even partial evidence would strengthen the analysis. Second, I think the routing-security section needs a small correction. ROV enforcement at the IXP would not have made these withdrawals cryptographically auditable. RPKI validates the origin of route announcements; it does not sign or authenticate withdrawals. Even BGPsec protects the announcement path, not the later removal of a route. A route server may of course log that a prefix disappeared, but ROV adds no cryptographic attribution to that event. The recommendation that IXPs and transit providers should state whether they enforce ROV is still a good one, but I would keep it separate from the events of 18 July. Third, the eight-hour limitation belongs to the RIPEstat view or endpoint used in the analysis, not to RIS itself. RIS also archives the updates received by its collectors in five-minute MRT files. The July 2024 events can therefore be reconstructed retrospectively without RIS Live and with much finer timing. This could show whether operators placed in the same eight-hour bucket actually withdrew minutes or several hours apart, and clarify how long the IPv6 stragglers remained visible. The MRT timestamp still records when an update was observed by a collector peer, not the exact moment a command was entered, but it would remove much of the ambiguity. I would be very interested to see a follow-up based on the raw MRT data. The combination of public collector data and direct operational experience is what makes this analysis particularly valuable. Thanks -- antonio”
Antonio, Thanks for this. One of the three I can close now, one I can only half close, and one you have given me a way to test. On BDIX, the part I can settle is the alternative you raise. For AS63526 the loss of international routing originated at the AS itself — my own account as the operator, not something the collector view can show — not at an IIG or transit edge failing underneath while domestic peering stayed up. So for at least one network the selective reading holds, on operational grounds rather than on the traffic graph. What I cannot settle is which of those prefixes stayed reachable domestically at the same moment, and the section should not have rested that on the graph. Your caveat about bilateral sessions is the binding constraint here rather than a footnote. Because a share of the peering at this exchange never touches the route servers, a prefix-by-prefix comparison would establish a lower bound on domestic visibility rather than measure it: presence in the logs is evidence, absence is not. That still helps, but it bounds how much the comparison can carry. I am asking what survives from that week, and will run the comparison if anything does. On ROV, the distinction you draw is the one the section missed. A route server can log that a prefix disappeared, but nothing in the deployed stack attests to the disappearance. The nearest thing in progress is the Signed Prefix List work, which makes absence checkable against a declared complete set, but that is a statement about what an AS may originate rather than an authenticated record that a route was removed at a given time. RFC 8205 is explicit about this at the edge of its own threat model: withdrawal suppression is left outside the protocol and deferred to certificate rollover. So the gap is architectural rather than a matter of deployment. Agreed that the recommendation should stand apart from 18 July. On the eight hours, one refinement: the interval is RIS's own per-collector RIB dump cadence surfaced through RIPEstat, rather than something RIPEstat introduces. Your point is unaffected, since the update files are the finer source either way, and I queried the wrong one. Your caveat about MRT timestamps is the real limit on what the timing analysis can claim, and I would rather be explicit about it than work around it. For AS63526 I can say which withdrawals were initiated at the AS rather than inferred from the collector view, which narrows the ambiguity for one network, but that is operator testimony and not a measured offset, and I will label it as such. Where the write-up gives times, they will be collector observations, and I will say so each time rather than let the two blur. You singled out the straggler prefixes, and that is where I will start, since it is the part I would most like to put on firmer footing. I would value your eye on it when it is ready. Kamruzzaman 1 Aug,2026
Showing 2 comment(s)