Minutes IETF125: bier: Thu 08:30
minutes-125-bier-202603190830-00

IETF 125 BIER Session Agenda
WG info: https://datatracker.ietf.org/group/bier/about/
Chairs:
Greg Shepherd (gjshep@gmail.com)
Tony Przygienda (tonysietf@gmail.com)
Secretary:
Zheng(Sandy) Zhang (zhang.zheng@zte.com.cn)

Thursday Session IV 16:30 - 18:00 Local time, Mar 19th, 2026

• WG Status, Chairs, 10 minutes

Gunter Van de Velde: draft-ietf-bier-ping has already addressed some
issues in IESG, but one remaining question for the WG to answer is: is
this draft a general solution for all dataplanes, or is it specifically
focussed upon the MPLS data plane. Another observation is that this IESG
is specificly sensitive for WG charters and require that documents on
ballot fall within WG charter (few document, and hence please before
sending documents to IESG verify if the document is covered by the
charter and add a few lines in the shepherd writeup on why the document
is believed to be charter compliant.

Tony Przygienda: Yes. I will check and react if necessary.

Hooman Bidgoli: For pim-signaling and mldp signaling draft, we'd like to
move them on.

Tony Przygienda: After the drafts are refreshed, we will proceed to the
next stage.

Gunter Van de Velde: Because IESG has a short timeframe, drafts that
have entered or are preparing to enter IESG should be able to quickly
respond to the modification requirements.

• BIER interop in EANTC 2026, Hooman Bidgoli, 20 minutes

Tony Przygienda: A unified solution is recommended and should be
standardized. Otherwise, there are too many different approaches to deal
with.

Hooman Bidgoli: Based on my experience participating in EANTC over the
past few years, problems will always arise. Therefore, I have listed our
current situation here in the hope that the working group will discuss
it together.

Toerless Eckert: When I presented the draft-zzhang-bier-payload-label
last time, my goal was to achieve uniformity and avoid distinguishing
between upstream and downstream labels. However, this might not prevent
some vendors from needing to differentiate between how to search for
global and context tables. Therefore, I still hope to consider this from
an implementation perspective.

Jeffrey Zhang: Yes, setting the proto field to 1 enables a lookup from
the global table, which is a resource-saving practice and is why RFC
9573 includes this. However, there are still implementations that can
put the label into the context label table.

Hooman Bidgoli: Hopefully, as more vendors join in the future, their
implementations will become available for reference. Suggestions can be
made regarding specific values, such as 1.

Jeffrey Zhang: I started working on the draft-zzhang-bier-payload-label
about two years ago, with the aim of reaching a consensus.

Toerless Eckert, Hooman Bidgoli: An information appendix for DCB can be
added for reference. It can be distinguished by a flag.

• draft-liu-rtgwg-llmsync-multicast-00, Yisong Liu, 10 minutes

Hooman Bidgoli: I think BIER is well-suited for this scenario.
Considering the AI payload, we can consider how to optimize BIER to
eliminate IP/UDP, etc.

Tony Przygienda: AI scenarios such as HPC may have multiple data
transmission methods, and different optimization requirements exist in
different scenarios.

Toerless Eckert: The basic idea is to replace unicast with multicast,
and BIER multicast technology can be considered. This eliminates the
overhead of establishing a multicast tree through signaling.

Tony Przygienda: BIER technology can be used with application-layer or
kernel optimizations. There are already some considerations for
improving BIER itself, such as sparse BIER. One of the best
presentations on that was showing the gap analysis chart for multicast
technologies and the one thing BIER misses is addressing sparse groups
for wich e.g. u-bier has been suggested.

• draft-ll-opsawg-ipfix-bier-00, Yisong Liu/Changwang Lin, 10 minutes

Tony Przygienda: Agree with this work, as it will help with BIER
deployment. However, if you provide the label field but don't know the
related information such as the sub-domain, it may be difficult to use
it for analysis. I encourage the draft to add a section dealing with the
correlation of the ipfix stream with the control plane generating BIFTs
and according labels. That does not mean that the draft has to solve the
problem but an outline of possible approaches will make the draft far
more interesting to someone deploying it.

Yisong Liu: The draft will be improved.

• draft-li-bier-scalable-data-plane-00, Zhiqiang Li, 20 minutes

Jeffrey Zhang: The forwarding table is pre-built. The claim that it
speeds up the interface forwarding table during forwarding is incorrect.
Because entries are aggregated based on the interface/neighbor,
forwarding for one interface/neighbor is completed in one step, and the
number of table lookups is the same as the number of copies.

Zhiqiang Li: The entries in the pipeline are pre-calculated and
generated.

Toerless Eckert: Haven't read the draft in detail. However, in our
existing tests, the device can support much larger networks. If there
are concerns about forwarding complexity, consider BIER-TE as an
example. BIER-TE uses the same BIER header and bits, and also forwards
through the interface. Even if you have a very long bitstring, only a
small subset needs to be processed on each router. Therefore, it's
already an optimized solution.

Tony Przygienda: The forwarding steps in RFC8279 are not normative. The
specific implementation can vary, but the processing logic must behave
in a manner indistinguishable from the described logic. Discussions on
the specific implementation's informational type draft are welcome and
helpful since one of the tenents of BIER architecture was that many
different ways to implement the forwarding plane are possible in silicon
optimizing for different hardware technologies and deployment scenarios.
We hope that two sections will be added to this draft: the first section
describes ECMP and its compatibility with RFC8279 behavior; and the
second section the impact of control plane changes on chip updates,
including memory aspects, especially under control plane flapping
conditions. In practical deployment the update rate of silicon is very
often the limiting factor rather than computation or control plane
update rates.

• draft-ietf-bier-frr-12, Toerless Eckert, 20 minutes

Tony Przygienda: This draft was returned to the working group from IESG
due to serious, unresolved issues during reviews. The authors are
encouraged to address those reviews and concerns before presenting the
work further since otherwise there is no reasonable way the WG can
progress the work.