**Session Date/Time:** 26 Jul 2022 19:00

# msr6

## Summary

The msr6 session was convened to explore the need and potential for a Multicast Source Routing over IPv6 (MSR6) solution. Presentations covered various use cases from global operators, detailing requirements for a scalable, stateless, and native IPv6 multicast. A significant portion of the session was dedicated to a lively discussion on whether a clear problem statement and demonstrable gaps in existing solutions existed to justify new work. Architectural purity, the definition of "native IPv6," and the reusability of the IPv6 ecosystem were key points of contention. A poll at the end of the session, asking whether participants clearly understood the problem statement, resulted in an even split. Consequently, the chairs, in consultation with the AD, decided to defer any discussions on chartering a working group and directed the proponents to further refine the problem statement on the mailing list.

## Key Discussion Points

*   **Problem Space and Requirements:**
    *   Proponents identified a growing need for a native, stateless, and large-scale IPv6 multicast solution to address modern network challenges.
    *   Key use cases presented included:
        *   **5G Transport Networks:** High dynamics with mobile subscribers, 30,000+ nodes, 10M+ receivers, aiming to avoid per-flow state and unnecessary encapsulation.
        *   **Large-Scale Data Centers:** Handling massive 5G core networks (e.g., China Mobile with 1 billion+ subscribers, 30K L3 switches) and HPC applications.
        *   **Enterprise Surveillance (Smart Cities):** Managing large numbers of cameras (e.g., 8 million in Beijing) generating huge data streams, requiring stateless network burden avoidance.
        *   **SD-WAN (Holistic):** Connecting up to 100K CPEs across multi-domain networks, requiring security (encryption) leveraging IPv6 extension headers.
    *   Core requirements for MSR6 included native IPv6 forwarding, stateless operation for scalability, handling extreme dynamics, and the ability to incorporate add-on features.

*   **Current Multicast Landscape and Perceived Gaps:**
    *   Existing solutions like MLDP, RSVP-TE, and PIM are widely deployed, particularly for video distribution in operator networks (e.g., Verizon's use of RSVP-TE for contribution/primary distribution and MLDP for secondary distribution).
    *   These existing technologies fulfill requirements such as lossless video delivery, fast reroute (50ms), and path protection.
    *   Proponents argued that existing stateful solutions create operational complexity and do not scale sufficiently for new, large-scale, dynamic IPv6 environments. Stateless solutions like BIER were seen as valuable but primarily optimized for MPLS, requiring multiple encapsulation layers in native IPv6.
    *   Critics argued that the presented use cases could be adequately addressed by existing solutions (e.g., EMBS for alerts, unicast to servers for surveillance cameras), and that a clear problem statement justifying *new* work with demonstrable gaps had not been established.

*   **Architectural Approach and "Native IPv6" Debate:**
    *   A central theme of MSR6 is to achieve "native IPv6" multicast, interpreted as hop-by-hop forwarding based on RFC 8200 rules using IPv6 extension headers (analogous to SRv6 for unicast).
    *   This was contrasted with the current BIER architecture, which was described as heavily optimized for MPLS, leading to multi-layer encapsulation when deployed in IPv6 networks.
    *   Significant debate arose regarding the definition of "native IPv6" and whether an IPv6 extension header for source routing constitutes native IPv6 forwarding or introduces architectural layer violations.
    *   Proponents stressed the importance of reusing the extensive IPv6 ecosystem (socket APIs, QoS, ACLs, IPsec, IPfix) which is facilitated by a native IPv6 forwarding plane, as opposed to replicating functionalities for different forwarding planes.

*   **SRv6 Adoption and MSR6:**
    *   While SRv6 is viewed by some as a precedent for stateless traffic steering in IPv6, its deployment in the US is noted as currently limited.
    *   Concerns were raised that MSR6 might be seen as "a solution looking for a problem," potentially building on a foundation (SRv6) whose broad industry adoption is still contentious. Proponents clarified that MSR6's reliance is on the IPv6 extension header mechanism for source routing, not necessarily SRv6 itself, and that the benefits of stateless multicast are foundational.

*   **Technical Viability and Operator Interest:**
    *   Proponents cited P4 implementations and Intel Tofino emulations of MSR6 solutions as proof of technical viability.
    *   Operators from China Unicom and China Mobile expressed strong support, highlighting the rapid increase in IPv6 traffic (e.g., 42% in China Mobile's 4G/5G networks) and multicast traffic (e.g., live streaming that currently uses unicast, wasting bandwidth). They emphasized the need for a simple, unified, IPv6-native multicast solution for their large, dynamic networks.

## Decisions and Action Items

*   A poll was conducted to ascertain if participants clearly understood the problem statement presented for MSR6. The results indicated an approximately even split between those who understood and those who did not.
*   **Decision:** Due to the lack of a common understanding of the problem statement, the chairs and AD decided that further development and clarification of the MSR6 problem statement are required. Discussions regarding forming a working group or chartering new work are hereby deferred.

## Next Steps

*   The proponents are directed to continue the discussion and refinement of the MSR6 problem statement on the IETF mailing list.