Minutes IETF123: bier: Wed 09:30
minutes-123-bier-202507230930-00

IETF 123 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)

Wednesday Session II 11:30-13:00 Local time, Jul 23rd, 2025

1. WG Status, Chairs, 10 minutes
   ** draft-ietf-bier-frr is delayed and has more time to address the
   received comments, AD will take it on IESG in September.

2. draft-zzhang-bier-payload-label-00, 20 minutes, Toerless Eckert
   ** Hooman: I agree with the results. This situation arises if a
   single vendor only supports one type of label. Labels assigned
   upstream or downstream should be supported.
   ** Jeffrey: Routers should support both types of labels. If two
   routers only support different types, then it won't work properly.
   Standardization helps provide a way to differentiate.
   ** Hooman: Nokia, Huawei, and Ixia support an upstream label value
   of 2. For interoperability with HPE (Juniper), they can also support
   a value of 1. Supporting both labels doesn't necessarily mean it's a
   bug.
   ** Tony: To support a full BIER implementation, routers should
   support both. The goal of standardization is to unify
   implementations.
   ** Toerless: Whether it's an upstream label, a DCB label, or an
   SRGB label, the draft defines the values used for MPLS.
   ** Jeffrey: If two vendors support different values, then it won't
   work properly. It's essentially up to the implementation to look up
   the label table.
   ** Tony: Standardization is about consistency and avoiding errors.

   ** Toerless: The label lookup semantics for contextual labels and
   global labels are different.
   ** Hooman: This is simply an implementation issue.
   ** Tony: More communication with vendors is needed to find the
   right direction.
   ** Mankamana: It seems to involve areas beyond BIER. Is it
   specific to BIER?
   ** Toerless: No, it's not specific to BIER. There are several
   possible scenarios, such as SR. This draft is intended to clarify
   usage, including BIER.
   ** Jeffrey: This draft needs to be processed quickly for
   interoperability testing.
   ----adoption vote: yes 9, no 0, no opinion 0.

3. draft-zhang-rtgwg-llmmoe-multicast-00, 20 minutes, Sandy Zhang
   ** Toerless: I'd like to know how much traffic is being sent to
   the experts here. When using PIM to send traffic to all experts,
   GPUs that don't need it will drop it. However, if the traffic volume
   is very high, this might not be a good approach.
   ** Jeff: The router you see in the gating function isn't a
   physical router, but a logical router. It's used to select experts
   to handle specific parts of the problem. Decisions take microseconds
   to make, so this problem doesn't fall under the category of
   traditional multicast. A multicast approach using the data plane is
   possible, but the control plane is impossible. It's very dynamic,
   with only microseconds between the decision to use a specific group
   of experts and the start of traffic. So there's no time for
   signaling. A lazy approach would be to use broadcast, but that
   obviously has many drawbacks. As the number of GPUs in a data center
   grows, the number of experts will also increase, potentially
   exceeding a thousand. Therefore, special handling of header size and
   other factors will be required. This is exactly the right place to
   address the problem.
   ** Tony: The data volume needs to be analyzed. Experts need to
   handle increasing amounts of context.
   ** Jeff: More experts means more all-to-all synchronization,
   meaning unicast. This doesn't result in increased traffic.
   ** Toerless: I'm just wondering if static multicast can be used.
   In this case, a BIER-like approach seems more appropriate.
   ** Tony: User-based BIER is also known as overlay BIER.
   ** Jeff: Efficient receiver encoding is required.
   ** Sandy: Let's use inference as an example to illustrate the
   traffic problem Toerless raises. The communication traffic depends
   on the number of output tokens. During the inference stage, each
   token is sent to the selected experts along with all previous output
   tokens. Therefore, the amount of data sent increases with the number
   of output tokens.
   ** Jeff: Currently, we're only using unicast. There's a trade-off
   between the cost and benefits of multicast.
   ** Tony: Let's see what switches can do. Sharp might be a
   successful example.
   ** Jeff: Reliability is paramount.
   ** Sandy: Multicast here may be used with reliable features such
   as LLR, CBFC defined in the UEC, and transport layer retransmission.

   ** Toerless: In financial use cases, experience with multicast
   deployment is the highest priority. In AI computing, packet loss is
   the most important factor. Experience with flow control and QoS
   might be helpful for this use case. But RMT may not be a good choice
   for this problem due to the lack of extensive deployment experience.

   ** Tony: We can look to some experience, such as IB, to address
   this issue.
   ** Tony: I think there are two interesting comments: from the
   working group's perspective, adopting it only on the switch might be
   a closer approach, and the other is the credit-based reservation
   proposed by Toerless.
   ** Sandy: This is a real need, and we'd like to see if network
   multicast can help.
   ** Toerless: Would like to see it collaborate with AIDC or AI4Net
   in the IRTF. We can analyze the data patterns in LLM and see where
   to discuss it in the IETF.
   ** Jeff: EVPN is an example. It has many multicast drafts, but 90%
   of deployments use ingress replication. If we have a good solution
   to this problem, we can actually deploy it. If not, we'll still use
   ingress replication or unicast.
   ** Toerless: In my experience, operators may be more concerned
   about the additional traffic than the efficiency gains. If the price
   is high, people may be hesitant to pay.

**End of the session