Stig: wg drafts recap Alvaro: just like any other draft we send the igmpv3/mldv2 to internet standard draft to him when ready. What they are looking for is that there are not a lot of changes, that the draft is stable. Hooman, pim-sr-p2mp-policy: Mike: We pinged the spring chairs about the related sr-p2mp-policy-yang draft. Spring chairs felt, based upon the intro, it would probably need to be done in spring. Since this yang draft includes replication segment and policy you may want to make it clearer in the intro. Hooman: perhaps we can split it into two drafts, one for pim policy and one for spring replication segment. Multiple vendors have implemented and deployed this sr-p2mp-policy solution. Mike: it makes sense to split the yang related drafts into two. Stig: is there any dependency on the yang drafts. Hooman: will talk to co-authors and figure it out. Needs to be a glue layer. Stig: Two yang drafts would need to wait for each other. Mike: Yes and the two (spring, pim) drafts will depend on each other as well at least policy depends upon replication segment. Stig: splitting yang drafts makes sense. Alternative is to keep in one draft and do a wglc in both wg. Mike: we will speak to spring chairs as well to keep coordinated. Toerless: how do we coordinate with spring on this in general? Stig: we will need cross review of drafts. Last calls across wg’s. Toerless: perhaps have a spring shepherd for our pim draft. Huaimo, srv6-p2mp-path-00 Stig: status for srv6 in general? Huaimo: multiple deployments now. In ietf srv6 unicast draft is mature and extensions igp are adopted and in wglc. Mike: srv6 is in spring and version 17. Passed last call. Hooman: interesting concept. Each one of the sid’s. on the root you are putting the sids on each other. So on the root could have 6,7 different sids stacked on top of each other. Huaimo: sid list is encoding the path. The sid list will present the tree including the structure of the tree, according to the sid list the sub tree will be known. Hooman: is it safe to say the sid list at minimum it needs to be all the leaf routers that want to receive the packet from the root. I need to push sid’s on top of the packet for the transit node to figure out where the packet needs to go. Huaimo: yes that is correct. All the sids for the leaves will be in the sid list. Someone from ZTE: If the root needs to carry the segment list for the whole p2mp tree what about the overhead problem? If you have 100 nodes it’ll be a very big packet, very long list. Huaimo: yes, sid compression mechanisms are being worked on in spring. Also if the tree is too big you can split into multiple subtrees. ZTE: Format of the multicast sid. We carry the number of branches and sids in subtree in argument part. Are we defining a new programming function? Huaimo: No its not new. For sid we have locator function arguments. We just define some argument for a special purpose. ZTE: Does the multicast sid only have local significance? Huaimo: No, we have two multicast sids. One is a node sid and the other is adjacency. One global and one local significance. Sergey: Is the multicast sid a new type of sid that’s being defined here or is it defined somewhere else. Huaimo: The multicast sid is a special kind of sid needing code point allocation. Sergey: my concern is that the multicast sid definition would need to be defined in a separate document. Huaimo: We currently have various types of sids, locator etc. Multicast sid is similar. Hooman: I’m not sure if there is a concept of splitting sids and putting them back together based on a replication node. Somehow we need to split a sid list into two. Coming from the root the sid list will include all the sids. Then sid lists need to be split. Huaimo: that’s correct. Sid’s have structure information and can easily obtain the information. Hooman: that splitting needs to be well defined in the draft. And this needs to be implemented correctly in the data path. Acee: The abstract needs consisely define differences between replication segment. What are the extensions to it. Huaimo: Replication segment has a lot more information, tree id, route id. Multicast sid is a simple sid. Mike: we will make that more clear in the draft. Stig, pim-igmp-mld-extension: Hoping we can do a last call soon if people have read it. We will take it to the list. Mike: may need to spell it out a bit more in the draft on how this can be used and interoperability concerns. Gyan, Reliable Multicast over the internet Jake: would suggest looking into FEC. Common way to solve reliability for multicast. Recommended for FLUTE and NORM. Would be a cool idea to make an rtp payload with FEC for iframes. But that may not be the way to go. QoS for interdomain will be a heavy lift. With FEC you don’t necessarily need to retransmit, you could do someone out of band. There’s other ways to do this without the hop by hop network support. Mike: you were wise to include detnet in your email earlier and it would be worth pursuing with that group as well. p2mp is included in the detnet charter. Gyan: I’ll follow up with detnet. And I’ll look at the rmt documents.