IETF 124 BIER Session

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)

Tuesday Session II 11:30 - 13:00 Local time, Nov 4th, 2025

1. WG Status, Chairs, 10 minutes

2. draft-ietf-bier-frr-11, Toerless Eckert, 10 minutes
   Greg: Have deep dive in the ver 10, would like to see the FRR
   unicast configuration of BIER shown in the draft, and show why so
   complex the examples are. To start from what BIER inherit, then go
   these examples.
   Toerless: Using unicast FRR really have an optimize. Will delete the
   complex example.

3. draft-zzhang-bier-payload-label-01, Toerless Eckert, 10 minutes
   Hooman: The service is specific per VRF. etc. no matter what the
   protocol is. Nokia and Huawei do it by context specific label. The
   protocol is useless.
   Toerless: two code points are not needed. Non-DCB capable router
   only treat it as context label.
   Hooman: For DCB-capable and non DCB-capable routers, two types are
   still needed. And for implementation, wrong implementation needs to
   be avoided. Even if all the routers support DCB, different protocol
   number may still be used.
   Hooman: in EANTC test, every company (Juniper, Huawei, Nokia)
   supports DCB, the interop problem is Juniper send BIER packet with
   protocol set to 1, Nokia and Huawei sent BIER packet with protocol
   set to 2.
   Toerless: mandatory methods need to be defined. Implementations may
   support both of them: DCB and non-DCB capable.
   Hooman: PTA signaling makes no difference how implementation deals
   with the DCB label. When the packet comes into the router, the label
   is the first to be executed and not the protocol. Maybe a new
   protocol number is needed for it.
   Ice: In my opinion when using DCB, it's still downstream assigned
   labels, so protocol 1 may be more suitable.
   Hooman: It's the hardware implementation.
   Toerless: for DCB label lookup it's described in the draft "can",
   not "must". Controller may do better.
   Jeffrey: two clarifications, the first is the arguments among us is
   if the BIER packet protocol should be set to 1 while using DCB. the
   second is that we don't support the upstream assigned label yet
   because we think DCB is a more efficiency way. But in the future if
   the market needs we can implement it.
   Hooman: we agree that protocol 1 can be used by DCB. It's a hack for
   me. But it may be better to use a new protocol number for DCB.
   Toerless: still think need to decide if DCB should be a mandatory.
   Jeffrey: It's not SRGB vs DCB. it's upstream assigned label vs DCB.
   RFC8556 uses upstream assigned label. there is no SRGB in BIER.
   Toerless: thinking about what we should do in BGP side as Tony said
   previously.
   Jeffrey: Not sure but in DCB RFC, it doesn't say it should be
   protocol 1 with BIER. May update the draft.

4. draft-zzhang-bier-optimized-use-in-aidc-00, Jeffrey Zhang, 15
   minutes
   Toerless: remember that may be in 2018 or 2019, somebody does
   stateless multicast in DC with very specific topologies. The
   research may do help for the topology-aware data center. BIER isn't
   limit by specific topology and can be used by any type of
   topologies.
   Toerless: I am not sure how easy or how difficult it be to get into
   the last hop, it may be done by the TOP switch. We can do static
   mapping for the multicast group to bitstring, or mapping for vlan to
   bitstring.
   Jeffrey: static mapping may work. the key issue is the ingress
   switch needs to know what bitmask needs to be encapsulated on the
   packet.
   Ice: can the source changed to send IGMP message to the first hop
   switch? maybe it more easy to changing the application to carry the
   BIER bitstring.
   Jeffrey: yes. it souce can do it then we need do nothing.
   Ice: if the source send IGMP proxy message? the application need to
   be changed?
   Jeffrey: yes. this is control plane. the application can send packet
   with bitstring and it's dataplane.
   Greg: are you asking the host to make a change?
   Toerless: application may send only UDP message.
   Jeffrey: both of them can be done.
   Toerless: communication library may be changed for sending the
   packet.
   Jeff: no VLAN here. According to the MoE architecture using
   multicast will improve the performance. The router decides the set
   of experts running on the GPU and it's a software. The expert's
   selection process takes only a couple of microseconds. There is no
   time to send reports. We need to separate the control plane and data
   plane. Dataplane is near real time and has no time to do this. We
   need no multicast on GPUs, we just need proxy signaling. This isn't
   traditional multicast.
   Toerless: Sender knows the destination experts which the packet sent
   to.
   Jeff: Yes.
   Toerless: communication library usually do the encapsulation and
   send the packet with UDP. The application needs to tell library the
   IP addresses of receivers. Library can send the packet by unicast or
   by multicast like BIER.
   Jeff: Call it replication may be more suitable. As the grow of
   group, thousand replication leads to less efficient.
   Toerless: the library should not be bothered that which technology
   will be selected for replication.
   Jeff: consuming GPU to do this isn't economic.
   Stig: about the format, are the IP addresses here the BFR prefixes
   for the host?
   Jeffrey: haven't be decided yet, it could be the BFR prefix, the
   BFR-id or whatever makes sense here.
   Stig: RFC7046 may do help for it.
   Toerless: how dynamic the set of receivers. If it's static then put
   them into signaling, if it changes packet by packet the only way to
   craft the bitstring in the sending host.
   Jeffrey: A comment received from PIM WG is the BIER part in this
   draft is informational, the IGMP extension part may make this draft
   to PIM WG. Do we need to split the draft into two parts, one in BIER
   WG and one in PIM WG? Or just one draft to be done in PIM WG.
   Stig: doesn't need two separate drafts. I think it should be done in
   PIM WG.
   Greg: Have productive conversation and an information draft makes
   sense. the position of draft will be decided later.
   Jeff: we are on early stage and we should work on this.