Sincere thanks to Sandy Zhang and Yao Liu for the minutes. ------------------------- - WG status -Chairs Jim[AD]: A revision of the RIFT Yang module is expected. Are you going to wait for the spec gone through or you are going to go ahead and do that now. Sandy Zhang: Some sections of the rift base draft have been changed so the referenced sections need to be modified in the YANG modelaccording to the newest RIFT base document. There's no technical modification after checking. - draft-ietf-rift-rift-20 Update on the base spec - Jordan Head Jeff T[Chair]: Thanks Jordan for the great work and persistence, readability has been impoving with each patch. Tony P(from the chat):The -20 has been fully pulled over open source version and interposed - Discussions on the new charter Tony: The muticast is very closely related to possible work we could do on in-network computation which right now we say AI/ML but it's a more generic concept, where you basically set up those trees to run net-reduce primitives. Jeff: New traffic patterns, we're going from kind of all-reduce,all-to-all to shuffle which is subset of all-to-all. This is where multicast or actually BIER-like multicast becomes really important and the ability to signal your compute capabilities becomes really interesting. RIFT seems to be the best suitable protocol to do. Really exciting to see these new cases which we didn't envision when we started but protocol well-designed leaves possiblities unlimited. Dmitry: If you are talking about AI and the ML and so on. Maybe it makes sense to explicitly talk about support for some subset of collect operations because that's what it's really about. When we we are saying multicast people usually bring a lot of historical baggage what they think about it. And here it's significantly different from what we usually mean by multicast networks. Jeff: Usually we see multicast something between unicast and broadcast,we could be more specific about exact meaning and how we are trying to use this. Sandy: We should not only limit it to dragonfly topologies for AI/HPC scenarios. The last sentence of the slide also says that RIFT will explore the use and extensions for AL/ML data center architectures. We may consider some deployment reports or some guidance for the user, because some operators are considering whether RIFT can be used in their networks. Some deployment guidance would be welcomed by them. Jeff: Always invite collaboration and new ideas here. Rift has numbers of truly unique characteristics that no other routing protocol can provide and seems to be really suitable to be used in backend networks. Jeff: If there's no disagreement, the new charter would be formally approved. Polls on "Agree/Disagree With Teh New Charter" Yes(12) No(0) No Opinion(0) Similar request and the charter would be also sent to the list. Jim: For the new charter, I'm assuming you've got some new charter text besides the slide. Specifically that you're gonna share with the working group. Jeff: Yes Tony: After the base spec is out, we still have the rift applicability and especially, I'll focus on reviewing and brushing up the YANG doc. The key value store is pretty far advanced there's tons of stuff there. Conceptually dragonfly is done, the rest is basically encoding, figuring out the details, maybe some implementations I invite folks, because I don't think anything like that has been done before ever. And of course the AI/ML can get hot if folks are interested in starting some new drafts. Some ideas in my mind, the ZTP for EVPN and flood reflection are largely in very good shape, the multicast is super interesting especially for in-network computation. Whoever has cycles and interest post me please. Jim: We can get some kind of prioritization on these different elements as well from the WG because that's quite a chunk of change right there. I don't wanna try and get a new charter through that's got everything in the kitchen sink, I'd rather be a little bit more specific, that's going to require some prioritization. What of these stuff is important to you and that's the stuff that should be really on the charter, because we can always recharter again to cover some of the stuff that is not necessarily going to get done for a while. Tony: it's hard for me, especially operational folks who want to use that come and push, that's where the energy will go. We can set the priority about whether the folks will work on that in this sequence, but there's no guarantee really. Sandy: Glad to hear that Tony has some new ideas on in-network computating or something else in AL/ML scenarios, of course many of us have interest in it and we'll join the work.