# Find MSR6 information Information about BOFs is not as easily indexed by datatracker as for approved groups, so we repeat the important URLs here for better orientation ## Datatracker ### BOF request details https://datatracker.ietf.org/doc/bofreq-liu-multicast-source-routing-over-ipv6msr6/ ### BOF Group overview / documents proposed for MSR6 https://datatracker.ietf.org/group/msr6/documents/ ### Meeting materials - also propose your slides here for chairs to find them easily https://datatracker.ietf.org/meeting/114/session/msr6 ## Github https://github.com/msr6-community ### presentations https://github.com/msr6-community/presentations Please add your slides to the presentations reposity. Ask tte@cs.fau.de to be added as writer to the repo # ------ Agenda ------ Official agenda see also: https://datatracker.ietf.org/meeting/114/session/msr6 ## 15:00 1. Chair introduction (5 minutes) ## 15:05 2. Use-case section (45 minutes) No Q&A here, but in open Mic slot ### 15.05 2.1 Use-cases (15 minutes) Presenter: Tianji Jiang (China Mobile, tianjijiang@chinamobile.com, onsite) Note: draft authors are only remote, presenter is onsite Draft: https://datatracker.ietf.org/doc/draft-liu-msr6-use-cases/ Slides: https://github.com/MSR6-community/presentations/blob/main/msr6-bof-liu-use-cases.pdf ### 15:20 2.2 Domestic use-cases for USA operators (15 minutes) Presenter: Gyan Mishra (Verizon, hayabusagsm@gmail.com, onsite) Slides: https://github.com/MSR6-community/presentations/blob/main/msr6-bof-chen-te-solution-overview.pdf ### 15:35 2.3 Use-case core operator requirements (15 minutes) Presenter: Toerless Eckert, (Futurewei, tte@cs.fau.de) Slides: https://github.com/MSR6-community/presentations/raw/main/msr6-bof-eckert-core-requirements.pdf ## 15:50 3. Solution Section (20 minutes) No Q&A here, except for understanding ## 15:50 3.1 MSR6 Best Effort drafts (10 minutes) For Drafts: https://www.ietf.org/id/draft-xl-msr6-source-segment-02.html, https://datatracker.ietf.org/doc/draft-lx-msr6-rgb-segment/ Presenter: (China Mobile) / Mengxiao Chen (New H3C Technologies, chen.mengxiao@h3c.com) (remote) Slides: https://github.com/MSR6-community/presentations/raw/main/msr6-bof-chen-be-solution.pdf Note: not presenting https://datatracker.ietf.org/doc/draft-chen-pim-be-mrh this time ## 16:00 3.2 MSR6 Traffic Engineering Solution overview (10 minutes) For Drafts: https://datatracker.ietf.org/doc/draft-geng-msr6-traffic-engineering https://datatracker.ietf.org/doc/draft-geng-msr6-rlb-segment https://datatracker.ietf.org/doc/draft-chen-pim-mrh6 https://datatracker.ietf.org/doc/draft-eckert-msr6-rbs (replacing draft-xu-msr6-rbs) https://datatracker.ietf.org/doc/draft-chen-pim-srv6-p2mp-path-06 https://datatracker.ietf.org/doc/draft-chen-pim-mrh6-03 https://datatracker.ietf.org/doc/draft-cheng-spring-ipv6-msr-design-consideration Presenter: TBD Slides (WIP): https://github.com/MSR6-community/presentations/blob/main/msr6-bof-chen-te-solution-overview.pdf ### 16:10 4. Open Mic/Discussions (20 minutes) Please no solution discussions today (too many technical details) Ideally discussion on use-cases, requirements and gaps of existing solutions. Solution section just served to show viability for the proposed WG to be on the right track to solve use-cases/requirements/gaps ### 16:30 5. Charter Discussion (15 minutes) Candidate items: Chairs/AD presenting charter Toerless would like to show slides (5 minutes) to explain: - Rich set of WG adjacencies we need to work with - Strict building of charter towards deliverables, e.g.: MVS, milestones Slides: https://github.com/MSR6-community/presentations/blob/main/msr6-bof-eckert-why-and-how.pdf ### 16:45 Conclusions, next steps (Chairs and AD, 15 minutes) # ------ Meeting Notes ------ (Adrian Farrel) ## 15:00 1. Chair introduction (5 minutes) No comments ## 15:05 2. Use-case section (45 minutes) ### 15.05 2.1 Use-cases (15 minutes) Presenter: Tianji Jiang (China Mobile, tianjijiang@chinamobile.com, onsite) Note: draft authors are only remote, presenter is onsite Draft: https://datatracker.ietf.org/doc/draft-liu-msr6-use-cases/ Slides: https://github.com/MSR6-community/presentations/blob/main/msr6-bof-liu-use-cases.pdf Greg Shepherd: What do you mean by native IPv6? Tinaji: Using IPv6 header without encap. Forwarding on the header as usual Greg: But you are using new forwarding information. So this is not native. Putting in an EH is not native Andrew Alston: You said "non-encapsulated". This is a violation of "limited domain" as specified in the 8784. Tianji: This is use case not solution Suresh: Defer to open discussion Stig: You talk about size of network, but size of tree or number of flows Tianji: Telco use case, ballpark 30k in tree, 100s of aggregation branches Stig: How many hosts in a flow? Tianji: 10 million receivers or so Stig: Sparse or dense tree? Tianji: Both ???: 10 million on same tree? Tianji: Within a city, and yes Hooman Bidgoli (remote): Should not count hosts. Tree starts at cell-side router. This problem has been solved for centuries. Major providers have multicast for these emergency message problems. OTOH cameras usually do uincast to server for reasons of security: consumers do join to server and cameras are not part of the multicast domain. Aijun Wang (remote): {Too fuzzy to understand} Weiqiang Cheng (remote): IPv6 traffic in telco n/w is increasing rapidly. 4/5G IPv6 traffic at CMCC has exceeded 42%. Expect a pure IPv6 netwook. CMCC backbone needs to support multicast. Suresh: Do you have a question or just agreeing with Tianji? Weiqiang: Yes, just clarifying Aijun: Example is live stream not only in 5G. {Remaining discussion moved to chat} Greg Shepherd: Why aren't we starting with a problem statement? We are seeing use cases not much different from things that can already be solved. I was hoping to see some gap analysis. ### 15:20 2.2 Domestic use-cases for USA operators (15 minutes) Presenter: Gyan Mishra (Verizon, hayabusagsm@gmail.com, onsite) Slides: https://github.com/MSR6-community/presentations/blob/main/msr6-bof-chen-te-solution-overview.pdf Greg Mirsky:Lossless and zero-delay switch-over. How will you achieve it? Gyan: Redundant paths as deployed today with replicated stream. Suresh: Rephrase, is it a non-negotiable requirement? Gyan: Yes Tom Hill: How would this work with paused live streams? Fall back to unicast or a new protocol? Gyan: Maybe talk about this in solutions Toerless: Ways to improve this being discussed in BIER, but not discussed in MSR6 yet Greg Shepherd: Sounds like your objectives to be "just as good as what is deployed today". Any gaps and improvements? Gyan: Trying to show existing situation. Previous slides talk about gaps? Greg: Didn't see any. Are your objectives simply to be "as good as what we have?" ### 15:35 2.3 Use-case core operator requirements (15 minutes) Presenter: Toerless Eckert, (Futurewei, tte@cs.fau.de) Slides: https://github.com/MSR6-community/presentations/raw/main/msr6-bof-eckert-core-requirements.pdf Greg Mirsky: What is "native IP"? Toerless: It is on one of my slides. Will come back to it later {Some fun swapping to a more recent slide deck} Greg Mirsky: What is alternative to native IPv6. IPv6 includes IPv6 and SRv6. Toerless: Forwarding not based on RFC8200. For example, MPLS or BIER. Greg: Then we have a different name. Toerless: So native IPv6 means IPv6 Greg: Stateless and simplicity of operation are counter to each other Toerless: It can be debated Stig: Sounds simple, but processing may be very different from IPv6. There may be some complexities Toerless: It is a steering header. But see solutions work Joel Halpern: I don't like hearing that this is "native IPv6". This involves a different representation and is not existing IPv6 {applause} Toerless: We can debate the term. This solution does 8200 forwarding rules. Greg Shepherd: There is misrepresentation of what happened in BIER. BIER is not a routing protocol, it is a forwarding paradigm. Suresh: Is BIER open to other encapsulations? Greg: Message from ADs when BIER was set up was "Don't mess with the forwarding plane" ### Open mic on problem statements ### {skipped solutions presentations} John Scudder (AD): Please be nice and not rude Tony P: I understand people like SRv6 and may have it in silicon. The problem with the use cases is that you can solve them with what you have today. There is no gap analysis. You could implement BIER on Ethernet and then carry IPv6 over that. I think this violates 6man and BIER architecture. This also stomps on several other WGs. We have had a discussion about encoding the encapsulation and that got us nowhere. Suresh: To summarise, you think we should start with the gap analysis Tony P: Yes. Toerless: This not meant to be BIER. Learn from BIER but be 8200 compliant. Not about layer vioaltions. It's about having to operate multiple forwarding planes. Xuesong Geng: People may remember discussions from BIER WG. But this is very different and not in scope of BIER. IPv6 is more friendly to host-initiated case. Look at solutions and see more about the benefits. Tom Hill: Claim is being made that operators fully understand the benefits of SRv6. At best this is contentious. I don't see this supposed interest from my peers operating networks. Are you starting from the right position? Toerless: I just want multicast to not be second class in the network. Do you want to forbid others from doing this? Tom: You want a WG, but how much should we invest on false premise? Toerless: Reason for stateless multicast is stronger than stateless unicast. Tom: I appreciate this. But must not state that operators really like SRv6 - should not rely on that. Toerless: {long answer and the notetaker got lost}. Don't want to replicate the ecosystem across another forwarding mechanism when we can just pick up the IPv6 Andrew Alston (not speaking as AD): Use case of SRv6 over public Internet is clear violation of 8754. Your use case is premised on this. 20 years ago we looked at source routing and said this is a bad idea and deprecated it. This is MSR6 so it *is* based on SRv6. I echo Tom and note the slide that said "very little deployment of SRv6 in the US" this makes MSR6 look like a solution looking for a use case. Toerless: I don't think we have any native multicast in the Internet. We should discuss more about the parts of the network where multicast goes in private networks and edge networks. Need to figure out who is interested in working on this. People who have competing opinions should not block work unless technical issues. Tianji: It's not like we have SRv6 and are looking for use case. We have a real multicast problem with ultra-scaled dynamic multicast. David Lamparter: Missing piece... How does moving the group membership to the responsiblity of the source help? Toerless: When we started BIER we said mcast is hard because we have to rouble shoot in the network. So we did ingress replication but it didn't scale so we have BIER. David: Is this just moving the problem from source discovery to destination discovery? Toerless: I think the same question applies to BIER and MSR6 Yisong Liu: As operator we have deployed IPv6 more and more with very large network. Potential mcast services also very huge. Need single and unified solution wihout state in network. Weiqiang Cheng: 1. IPv6 traffic is increasing rapidly. CMCC 4G/5G network IPv6 traffic is now at 42% and has increased dramatically. Expect near future almost all traffic will be IPv6. Need to prepare for that. IPv6 native network is such preparation. Weiqiang Cheng: 2. Mcast traffic is increasing dramatically. E.g., video. Currently using unicast in telco n/w. Existing mcast slution cannot address this. IETF should prepare for this new situation. As operator engineer I suggest IETF consider new solution. Zhenbin Li: No time for presentation of solution, so I will talk about it now. BIER-TE is not scling enough for use cases, so need solution to combine SRv6 segment and bitstring solution. Hao Li: Would be good to have a complete solution for MSR6 Tinaji: This problem is real problem. unfortunately no time to present technical solution, but the slides show this should be and can be done in IETF. Side meetings show subject matter experts in IETF have interest. Hackathon shows P4 emulation of MSR6 can be done. Furry relays a message from the chat: {find it and copy it in} Dino: Surely you owuldn't put 10000 receivers in the source route. So you will need overlays Toerless: So, number of PEs is the number. But sparely populated fat bitstrings, is inefficient Sirja Li: Have university project in hackathon for MSR6 solution. XueRue Zhang: Mentioned P4 implementation of MSR6 BE. This was shown at Hackathon: https://github.com/IETF-Hackathon/ietf114-project-presentations/blob/main/P4%20implementation%20and%20emulation%20of%20MSR6%20BE%20(Multicast%20Source%20Routing%20over%20IPv6--Best%20Effort).pdf Tianji: 10000 receivers is reasonable. ### 16:55 Conclusions, next steps (Chairs and AD, 15 minutes) Suresh: Poll of room using meetecho. Is problem to be solved clear? "Do you believe you understand what the problem is?" Not "do you agree with the problem?" Clear : 53 Not clear : 52 Concludes that problem statement needs more work and focus on mailing list. No point in talking about charter until problem statment is clear