arxiv: 2605.07071 · v1 · submitted 2026-05-08 · 💻 cs.NI

Recognition: no theorem link

From Map-and-Encap to BIER: Observations on Network Routing Scalability

Tianyuan Yu , Lan Wang , Beichuan Zhang , Lixia Zhang

Authors on Pith no claims yet

Pith reviewed 2026-05-11 01:08 UTC · model grok-4.3

classification 💻 cs.NI

keywords routing scalabilitymap-and-encapmulticast deliveryBGP protocolnetwork architectureunicast routingBIER

0 comments

The pith

Map-and-encap is the recurring architectural solution for scalable routing in both unicast and multicast.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper examines the history of routing scalability challenges caused by IP addresses serving both identification and location roles. It finds that map-and-encap, which separates these roles through encapsulation, has been independently reinvented in various unicast and multicast solutions. A reader should care because the paper's four observations explain why some solutions are adopted quickly and why others, including today's BGP, hit scalability walls. The review concludes that future designs must provide topological abstractions and local benefits to succeed.

Core claim

All scalable unicast and multicast delivery methods share the map-and-encap solution developed independently. Successful new solutions offer immediate local gains without cross-domain coordination. Designs depending on the number of end sites or application-specific deliveries cannot have an upper bound on scalability. BGP lacks a topological abstraction like an egress router, preventing a map-and-encap solution for scalability.

What carries the argument

map-and-encap, the pattern of mapping host identifiers to network locations and encapsulating packets accordingly to achieve scalability

If this is right

Solutions that bring immediate benefits to early adopters are more likely to be adopted.
Routing designs must avoid dependence on the count of end sites to remain scalable.
BGP requires an equivalent to an egress router abstraction to enable map-and-encap.
Both unicast and multicast scalability rely on the same underlying architectural pattern.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

BIER represents a modern multicast approach that may fit within this map-and-encap framework.
Inter-domain routing could benefit from adding topological abstractions similar to intra-domain ones.
These observations could guide the design of routing for new network types like IoT or 5G.
A complete review might miss novel approaches that break the pattern.

Load-bearing premise

The historical solutions reviewed represent all possible approaches and the observations will generalize to future designs without further testing.

What would settle it

Identification of a scalable routing design that does not rely on map-and-encap or one that bounds scalability despite depending on the number of distinct end sites.

Figures

Figures reproduced from arXiv: 2605.07071 by Beichuan Zhang, Lan Wang, Lixia Zhang, Tianyuan Yu.

**Figure 2.** Figure 2: An example scenario of MPLS, which replaced [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Figure 3: Comparison of different multicast forwarding designs. Left: stateful multicast requires routers to maintain [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

read the original abstract

The TCP/IP protocol stack uses IP addresses for two distinct roles: identifying hosts and locating their attachment points in the network topology. This dual purpose creates a fundamental tension that has led to routing and forwarding scalability challenges throughout the history of the Internet in unicast packet delivery and, more notably, in multicast delivery. This paper reviews the evolution of routing scalability solutions over the years and makes four observations. First, map-and-encap is a recurring architectural solution shared by all scalable unicast and multicast delivery methods, developed independently across different problem contexts. Second, a new solution tends to succeed when it can bring immediate local gains to early adopters without requiring coordination across administrative domains. Third, network routing and forwarding designs that depend on external factors, such as the number of distinct end sites or even application-specific deliveries, inherently preclude an upper bound on their scalability. Fourth, today's inter-domain routing protocol, BGP, lacks a topological abstraction equivalent to an egress router within a routing domain, thereby inherently preventing a map-and-encap solution for scalability. These observations offer insights into the design of future scalable routing system architectures.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

This is a historical review that frames map-and-encap as the repeated pattern in scalable routing and flags why BGP lacks the needed abstraction, but it adds no new measurements or proofs.

read the letter

The main thing to know is that the paper reviews decades of unicast and multicast routing work and boils it down to four observations, with the strongest being that map-and-encap keeps appearing as the practical way to separate identity from location without blowing up state. The authors walk through examples from early proposals to more recent ones and note how each arrived at similar structures independently. They also point out that solutions only spread when early users see local benefit without needing global coordination, and that any design tied to the number of end sites or applications will hit a scalability wall. The fourth observation is that BGP has no clean equivalent to an egress router abstraction inside a domain, which blocks a map-and-encap fix at inter-domain scale. That last point is the most directly useful for people thinking about future architectures. The paper does a clean job organizing the timeline and making the pattern visible without overclaiming. The writing stays focused on the engineering trade-offs rather than hype. The soft spots are straightforward. These are observations drawn from the cases the authors chose to include, not a formal completeness argument or fresh data. A reader could reasonably ask whether other approaches were left out or whether the pattern holds once you include more recent proposals that the paper does not cover in depth. The BGP limitation claim is plausible from the description but would benefit from a short concrete example of what an egress abstraction would look like and why it cannot be retrofitted. No equations or measurements are present, so the strength rests entirely on the historical narrative being accurate and representative. This paper is aimed at network researchers and architects who already know the BGP and multicast literature and want a compact framing for why certain scalability problems persist. A reader working on clean-slate or incremental routing designs will find the observations worth keeping in mind when evaluating new proposals. It is not a result paper, so it will not change anyone's core technical toolkit, but the synthesis is clear enough to deserve referee time. I would send it to review in a venue that publishes architectural or position papers rather than desk-reject it.

Referee Report

1 major / 2 minor

Summary. The manuscript reviews the evolution of routing scalability solutions in the TCP/IP stack, attributing challenges to the dual role of IP addresses in host identification and topological location. It synthesizes historical developments in unicast and multicast delivery, culminating in four observations: map-and-encap as a recurring independent solution across scalable methods; the importance of local gains for adoption without cross-domain coordination; the inherent lack of scalability bounds in designs dependent on external factors like end-site counts; and BGP's missing topological abstraction equivalent to an egress router, precluding map-and-encap. These observations are positioned to guide future scalable routing architectures.

Significance. If the observations accurately capture the historical patterns, the paper provides a useful synthesis that highlights architectural commonalities in routing scalability solutions. This could inform designers by underscoring the value of map-and-encap patterns and incremental deployability. The strength lies in connecting independent developments across unicast and multicast contexts, offering a broader perspective than individual protocol analyses. However, as an observational review without new measurements or proofs, its impact depends on the completeness and accuracy of the literature synthesis.

major comments (1)

The fourth observation (BGP lacks a topological abstraction equivalent to an egress router, thereby preventing map-and-encap) is load-bearing for the paper's claim about inherent limitations in current inter-domain routing. The manuscript should provide a concrete contrast, e.g., by citing specific intra-domain mechanisms (such as those in OSPF or IS-IS) that supply the missing abstraction and showing why BGP's AS-level view does not, to substantiate why this precludes scalable solutions.

minor comments (2)

The abstract states that the four observations 'offer insights into the design of future scalable routing system architectures,' but the manuscript should clarify the bounded scope of the review (i.e., that it is not an exhaustive taxonomy) to avoid implying prescriptive generality without additional validation.
Ensure that each of the four observations is explicitly tied back to specific historical examples or cited works in the body text, so readers can trace the derivation of the takeaways from the literature review.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the detailed review and the constructive suggestion regarding the fourth observation. We agree that a concrete contrast with intra-domain mechanisms will help substantiate the claim and will revise the manuscript accordingly.

read point-by-point responses

Referee: The fourth observation (BGP lacks a topological abstraction equivalent to an egress router, thereby preventing map-and-encap) is load-bearing for the paper's claim about inherent limitations in current inter-domain routing. The manuscript should provide a concrete contrast, e.g., by citing specific intra-domain mechanisms (such as those in OSPF or IS-IS) that supply the missing abstraction and showing why BGP's AS-level view does not, to substantiate why this precludes scalable solutions.

Authors: We agree this elaboration will strengthen the presentation. In the revision we will add a brief contrast: intra-domain link-state protocols such as OSPF and IS-IS maintain a complete topology database within an AS, allowing routers to identify and select specific egress points for map-and-encap (as exploited by intra-domain solutions like LISP). BGP, by design, exchanges only AS-path vectors across administrative boundaries and does not expose or maintain equivalent internal topological detail, so no comparable egress-router abstraction is available for inter-domain map-and-encap without violating the AS autonomy model. This difference is what the observation highlights as precluding scalable inter-domain map-and-encap. revision: yes

Circularity Check

0 steps flagged

No significant circularity in observational synthesis

full rationale

The paper is a historical literature review that identifies recurring patterns across independently developed routing solutions and states four observations as direct takeaways. No equations, derivations, fitted parameters, or load-bearing self-citations appear in the argument structure. The central claim (map-and-encap as a recurring pattern) is explicitly bounded by the examined cases rather than asserted as a completeness proof, and the observations do not reduce to any input by construction or self-reference.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is a qualitative historical review with no quantitative model, so the ledger contains no free parameters, axioms, or invented entities.

pith-pipeline@v0.9.0 · 5500 in / 1126 out tokens · 39315 ms · 2026-05-11T01:08:32.967607+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

22 extracted references

[1]

Atkinson and Saleem Bhatti

Randall J. Atkinson and Saleem Bhatti. 2012.Identifier-Locator Network Protocol (ILNP) Architectural Description. RFC 6740. RFC Editor. https: //datatracker.ietf.org/doc/rfc6740/

2012
[2]

Bidgoli, S

H. Bidgoli, S. Venaas, G. Mishra, Z. Zhang, and M. McBride. 2025. PIM Signaling Through BIER Core. Internet-Draft draft-ietf-bier-pim- signaling-13. IETF. https://datatracker.ietf.org/doc/draft-ietf-bier- pim-signaling/ Work in Progress

2025
[3]

David D. Clark. 1988. The Design Philosophy of the DARPA Internet Protocols. InProceedings of the ACM SIGCOMM Conference. 106–114

1988
[4]

Farinacci, V

D. Farinacci, V. Fuller, D. Meyer, and D. Lewis. 2013.The Locator/ID Separation Protocol (LISP). RFC 6830. IETF. https://datatracker.ietf. org/doc/html/rfc6830

2013
[5]

2022.The Locator/ID Separation Protocol (LISP)

Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis, and Alberto Cabellos. 2022.The Locator/ID Separation Protocol (LISP). RFC 9300. In- ternet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc9300

2022
[6]

Farinacci, F

D. Farinacci, F. Maino, V. Fuller, and A. Cabellos. 2022.Locator/ID Separation Protocol (LISP) Control Plane. RFC 9301. IETF. https:// datatracker.ietf.org/doc/html/rfc9301

2022
[7]

2016.Protocol Independent Multicast — Sparse Mode (PIM-SM): Protocol Specification (Revised)

Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas, Rishabh Parekh, Zhaohui Zhang, and Lianshu Zheng. 2016.Protocol Independent Multicast — Sparse Mode (PIM-SM): Protocol Specification (Revised). RFC

2016
[8]

https://www.rfc-editor.org/ rfc/rfc7761

Internet Engineering Task Force. https://www.rfc-editor.org/ rfc/rfc7761
[9]

Vince Fuller. 2007. The Future of Routing Scalability. APRICOT 2007 Conference. https://www.apricot.net/apricot2007/presentation/ apia-future-routing/apia-future-routing-vince-fuller.pdf Presentation slides. 6 From Map-and-Encap to BIER: Observations on Network Routing Scalability Conference’17, July 2017, Washington, DC, USA

2007
[10]

Fuller and D

V. Fuller and D. Farinacci. 2013.Locator/ID Separation Protocol (LISP) Map-Server Interface. RFC 6833. IETF. https://datatracker.ietf.org/doc/ html/rfc6833

2013
[11]

L. Geng, J. Xie, M. McBride, G. Yan, and X. Geng. 2020.Inter-Domain Multicast Deployment using BIERv6. Internet-Draft draft-geng-bier- ipv6-inter-domain-02. IETF. https://datatracker.ietf.org/doc/draft- geng-bier-ipv6-inter-domain/ Expired

2020
[12]

1996.New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG

Robert Hinden. 1996.New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG. RFC 1955. Internet Engineering Task Force. https: //www.rfc-editor.org/rfc/rfc1955

1996
[13]

Maino, V

F. Maino, V. Ermagan, A. Cabellos, and D. Saucez. 2022.Locator/ID Separation Protocol Security (LISP-SEC). RFC 9303. IETF. https:// datatracker.ietf.org/doc/html/rfc9303

2022
[14]

2007.Report from the IAB Workshop on Routing and Addressing

David Meyer, Lixia Zhang, and Kevin Fall. 2007.Report from the IAB Workshop on Routing and Addressing. RFC 4984. Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc4984

2007
[15]

J. Moy. 1994.Multicast Extensions to OSPF. RFC 1584. IETF. https: //datatracker.ietf.org/doc/html/rfc1584

1994
[16]

Rosen, A

E. Rosen, A. Viswanathan, and R. Callon. 2001.Multiprotocol Label Switching Architecture. RFC 3031. IETF. https://datatracker.ietf.org/ doc/html/rfc3031

2001
[17]

Rosen, Mahesh Sivakumar, Sam Aldrin, Andrew Dolganow, and Tony Przygienda

Eric C. Rosen, Mahesh Sivakumar, Sam Aldrin, Andrew Dolganow, and Tony Przygienda. 2019.Multicast VPN Using Bit Index Explicit Replication (BIER). RFC 8556. RFC Editor. https://www.rfc-editor.org/ info/rfc8556

2019
[18]

Greg Shepherd. 2014. Bit Index Explicit Replication (BIER). Presented at IETF MBONED BOF, IETF 91, Honolulu, HI. https://www.ietf.org/ proceedings/92/slides/slides-92-mboned-5.pdf

2014
[19]

Waitzman, C

D. Waitzman, C. Partridge, and S. Deering. 1988.Distance Vector Multicast Routing Protocol. RFC 1075. IETF. https://datatracker.ietf. org/doc/html/rfc1075

1988
[20]

2017.Multicast Using Bit Index Explicit Repli- cation (BIER)

IJsbrand Jan Wijnands, Eric Rosen, Andrew Dolganow, Tony Przy- gienda, and Sam Aldrin. 2017.Multicast Using Bit Index Explicit Repli- cation (BIER). RFC 8279. Internet Engineering Task Force. https: //www.rfc-editor.org/rfc/rfc8279

2017
[21]

X. Xu, T. Przygienda, A. Gulko, S. Satapati, and I. Wijnands. 2024.BGP Extensions for BIER. Internet-Draft draft-ietf-bier-idr-extensions-19. IETF. https://datatracker.ietf.org/doc/draft-ietf-bier-idr-extensions/ Work in Progress

2024
[22]

Zhang, E

Z. Zhang, E. Rosen, D. Awduche, and G. Shepherd. 2022.Multicast/BIER As A Service. Internet-Draft draft-ietf-bier-multicast-as-a-service-03. IETF. https://datatracker.ietf.org/doc/draft-ietf-bier-multicast-as-a- service/ Work in Progress. 7

2022