Notes taken in etherpad at https://notes.ietf.org/notes-ietf-121-mboned# Text captured on 11/08/24: IETF 121 Dublin MBONED Wed, Nov 6, 2024 15:00 - 16:30 GMT Wednesday Session III, Liffey Hall 1 Chat Log: https://zulip.ietf.org/#narrow/stream/101-mboned/topic/ietf-121 Video log: https://youtu.be/pw_hNdbnAuM?t=122 Full session recording (incl transcript, polls, chat, video,etc): https://meetecho-player.ietf.org/playout/?session=IETF121-MBONED-20241106-1500 Blame for notes: Kyle Rose, Apologies: the network and/or HedgeDog appears to be lagging, so some text might be lost or mangled Status of WG items Chairs, 15 min Max bashed the agenda to move Louis’ talk before his to establish context. Lenny agreed. Sandy: draft-ietf-mboned-multicast-yang-model and draft-ietf-mboned-redundant-ingress-failover are ready fpr WGLC Lenny: please request WGLC on mailing list Jeffrey: draft-zzhang-mboned-non-source-routed-sr-mcast is stable and mature- would like to req WG adoption Lenny: please request on mailing list Adaptive Unicast to Multicast Forwarding (draft-liu-mboned-adaptive-utom) Yisong Liu, 10 min Tim: What is the problem stopping the internet service system from sending into the network (Sorry, I couldn’t figure out what Tim was asking…?) Jeffrey: What’s the advantage of PEs as multicast vs. traditional CDN method (nodes in a distributed network)? As long as the CDN servers can be deployed to where the PE servers are, it winds up being the same basic thing. Mankamana Mishra: Check out white paper “Multicast-assisted unicast delivery” https://www.ibc.org/download?ac=24594 Toerless: Outline more detail about the typical use-case, including devices that have various problems reliably receiving multicast traffic. This can work well if the sending server is closely coordinated with the network, but the draft does not explain this. Ran out of time, authors encouraged to take discussion to the list IPv6 Multicast in BSV Blockchain Network Jake Jones, 20 min Mike: IPv6 multicast comes in between the nodes in the network? A: Wallets, overlays as middleware, and the network is at the center. Big corporations are the nodes. Mike: Just the network using IPv6 multicast? A: Yes Mike: excited about Blockchain use cases for multicast. Would like to write a draft. Is this in charter for MBONED? Lenny: Probably, as multicast deployment use-cases are w/in mboned charter Warren: It depends on what the document actually says Some clarification of how and why the protocol leverages IPv6 multicast Tim: Private multicast deployments only? Or something else? A: Open to other options Toerless: Looking for more detail on what the physical networks look like Flexicast Extensions for QUIC (draft-navarre-quic-flexicast) Louis Navarre, 15 min Toerless: Does QUIC have a way to do replicated unicast? If so, then multicast would be an under-the-hood optimization. François Michel: Nice thing if this can be done transparently without changes to a QUIC client application (presumably the use of the API). Tim Chown: Clarifying that one path is unicast, and another is multicast. Tim: Has anyone tried doing something/interested in something like this? A: There is a WG for this (didn’t catch where that was) Lenny: What is the state of the implementation? Is it in a browser? A: Browser should be feasible, but unclear if it works now. And it would probably need to have the new quiche implementation swapped in to receive multicast (or even multpath?) Max: Browsers don’t have UDP API, and multicast is (almost) always UDP. And QUIC implementation in Chromium is a mess. Browser authors don’t like it because of privacy concerns among other things. Will take significant effort to get it upstreamed. Multicast QUIC (draft-jholland-quic-multicast-05) Max Franke, 10 min François Michel: Asked for clarification about meaning of the graph early in the deck about number of clients can be served. Lucas: Unclear what kind of demand there would be for standardization of this work in the QUIC WG, because lots of participating companies will just ignore it and do their own proprietary thing. Toerless: Multicast is conceptually just replication as a service. Identify the app first, then whether there is a problem there that would benefit from a MC-based solution. Survey on the state of SSM Support Max Franke, 10 min Lenny: Are you saying that there’s no IGMPv3/MLDv2 support for JOIN_SOURCE_GROUP, etc.? A: There are no API calls for it. Stig: A goal of the SSM interface was to avoid having it differ based on address family. It should work on all three OSes listed. A: Didn’t work on MacOS as of ~6 months ago. No packets were sent or received. More discussion and notes about SSM support on IPv6 -Ran out of time, encouraged to take discussion to the list Bandwidth aware multicast Max Franke, 5 min Max: Low on time, started with question: Is there any work where you take sources’ bandwidth requirements into consideration when you create trees? Stig and Toerless indicate some work in this area. (Add references if you want them recorded here) Missed the last speaker: no badge, not in queue Optimizing multicast traffic distribution on the local LAN Nate Karstens/Joseph Huang, 5 min Out of time, so went to slide 6 as an intro to problem statement and a teaser for full talk on Fri at PIM WG