IETF 116 Yokohama MBONED Agenda Wed, Mar 30, 2023 15:30-17:00 JST Wednesday session III, G412-G413 Note-taker: Nate Karstens Chat Log: https://zulip.ietf.org/#narrow/stream/mboned Video log: https://www.youtube.com/watch?v=FOiD870r_KY Notes taken in etherpad at https://notes.ietf.org/notes-ietf-116-mboned# Text captured on 3/30/23: Lenny reviewed the Note Well, asked people to log in online, and reviewed the masking policy Reviewed status of active WG docs: draft-ietf-mboned-mulitcast-telemetry – not enough non-author supporters to advance the draft draft-ietf-mboned-multicast-yang-model draft-ietf-mboned-redundant-ingress-failover MTTB (multicast to the browser) drafts: draft-ietf-mboned-dorms draft-ietf-mboned-ambi draft-ietf-mboned-cbacc draft-ietf-mboned-mnat Jake has been reassigned, so if anyone is interested in taking them over they are encouraged to do so Yisong Liu (remotely) presented “YANG Model for Automatic Multicast Tunneling” Version 02 – added statistics on AMT gateway Next steps – questions and ask for WG adoption No questions Lenny took a poll on who had read the AMT YANG draft 6 have read, 6 have not Lenny took an poll on who supports adoption 9 support adoption, 0 do not support adoption Will start an adoption call on the mailing list shortly Dino presented GAAP (draft-farinacci-pim-gaap-02) Based off of work in pim group based on problem from Nate Decentralized multicast group address allocation protocol (no central entity) GAAP nodes have zero configuration No collisions at L2 to support multicast snooping functionality Supports both IPv4 and IPv6 Works on both L2 and L3 Networks that do not support L3 can use overlays on L2 Can coexist with other group allocation protocols by using an IANA GAAP allocation block How does it work Both senders and receivers participate Hashes group name to calculate group address Claim messages sent every minute (+/- 10%), but designed to only have a single claimer Handles collisions by adding “+1”, “+2”, etc. to group names Provides partition repair Messages are encrypted with Chacha20 cipher, key is group name GAAP only has a single message – the claim message Protocol can detect bad actors (sending too fast, forging timestamp, etc). Rekeying can occur. Protocol API Four calls: init(), allocate(), release(), and close() A lightweight app can use a lighter-weight REST API to a GAAP proxy node that runs the protocol Need to experiment with IoT and using both Python and C GAAP library First phase implemented in Python Suite of utilities to help simulate collisions, partitions, etc. Question from Stig: Noticed that claim message has both v4 and v6 address field. Dino indicated this was on purpose for now (wanted to allocate both at once for now) Stig asked if we could have one number calculate both Dino indicated there were complications with handling collisions and needing to support multicast snooping Another question from Stig: Demo uses link-local scope Dino indicated that was an oversight May need to think about how scoping works Some talk about dividing existing allocations into different blocks Nate mentioned that he had a document that describes that, sent to Dino and will send to Stig Played video of demo. Used docker bridge to provide single-subnet multicast capability Dino mentioned simulations they ran with different collisions Next steps More testing More security features (Shamir’s MPC algorithm) Test on an overlay when no native multicast exists Seek more developers Write something in C to meet Nate’s embedded environment Acknowledgements Zheng Zhang Liked protocol design Wanted to understand if link-local, site-local, etc. would be used Dino indicated he wanted to use global scope (ff01) Stig Venaas Which protocol is being used to accomodate assignment of both v4 and v6? Dino: Needs to go over both to support collision detection Two messages need to be sent Dino indicated he would update to make that clearer Siyu Chen Asked for additional simulation data for collisions Also asked why we can’t avoid the issue with configuration When a collision happens, how long will it take to solve it? Dino answered 1 second Nate Pointed out that zero-configuration comes from his requirements Clarified that the global scope is ff0e Adoption call Might be an adoption call in pim No rush on this Plan to do additional testing and presentations Need to figure out GAAP and mDNS, or just one of them Enhancements to Signal-Free LISP Multicast (presented by Prasad Govidan, co-authored with Dino and Aswin) Problem statement: RFC 8378 defines signal-free mechanisms for an ingress replication-based underlay for overlay multicast Scope: keep the overlay signal-free semantics intact Reviewed procedures defined in the draft and showed diagram of reference model Question from Dino Mentioned that Daryl made comment in LISP working group. Wanted to know if some of the members are not on the overlay at all Prasad mentioned he would look into it Lenny asked if they were looking for feedback from LISP or mboned. Prasad asked chairs which WG they thought it belonged it Stig indicated that it was heavy on LISP content so thought it belonged there TreeDN: Tree-based CDNs for Live Streaming to Mass Audiences (Lenny - presenter, Chris Lenart, Rich Adam) draft-ietf-mops-treedn – also presented in mops WG and that group asked for more feedback from mboned to review multicast aspects of this Problem: With live audiences exploding (10s of millions) and increased bit rates (4K/8K/AR), are we at an inflection point? If so, what should we do? Live streaming is not the same as on-demand. Expectations for low latency means shorter playout buffer Join rates are vastly different Believes addressing the problem with network-based replication is correct, but Internet multicast has not been successful “All or Nothing” problem “It’s Too Complex” problem “Chicken and Egg” problem Good news: Network Replication technologies are now available to address those problems – TreeDNs TreeDN (Tree-based CDNs) Leverages native and overlay concepts to deliver service to end users Native (On-Net): SSM Overlay: AMT (RFC 7450) Incremental Deployment Showed diagram Benefits More efficent Allows SPs to offer new Replication-as-a-Service (RaaS) Democratizes and decentralizes content sourcing Use Cases / Applicability Any multi-destination content (live-streaming, large file downloads) Summary Crossing supply/demand curves Demand: exploding LiveStream audiences and increasing bitrates (4K/8K/AR) Supply: network-based replication is easier and more available than ever Feedback from MOPs Add diagrams Gaps - what else is needed to deliver a useful product? Transport issues with non-TCP traffic Scope - point out the gaps, not necessarily the solutions MOPs would welcome review and input from MBONED Question from Zhaohui (Jeffrey) Zhang: have they thought about working with MeetEcho team to use TreeDN to broadcast a few small sessions, like MBONED Yes, they have, thanks for the reminder. Jeffrey recommends starting here (i.e., an IETF meeting)