IETF 104 Prague MBONED Meeting mins Thurs, Mar 28, 2019 10:50AM-12:20PM Karlin 3 Jabber Log: https://www.ietf.org/jabber/logs/mboned/2019-03-28.html Audio log: https://ietf.org/audio/ietf104/ietf104-karlin3-20190328-1050.mp3 Video log: https://www.youtube.com/watch?v=jIDYHFpJYV8 Note taker: Toerless Remote participants: Wayne Brassem (Warren Kumari - also local) ----- Chair slides Chairs reviewing active WG docs, most of them shown here today, most of them likely ready for WGLC . Sandy would like more review of mboned-multicast-yang-model-01! Other docs: jholland-mboned-ambi-01 Jake Holland: Please take a look at this, Jake wants to make a viable attempt at implementing for browsers. Browsers need authentication to accept. Its unclear whether this doc itself should go through mboned (as opposed to other group), but must have mboned review. He will also do another update (hopefully before montreal). ----- Charlie Perkins: multicast considerations over 802.11 wireless media Update after IETF103.a mostly editorial comments (see first slide of presentation). Discussion from hackathon, email from David lamparter / Jake holland. Greg Shepherd: been following this thread too. What "commercial solution" room consensus: APs (jake) Toerless: only new thing seems to be the automatic choice , conversion to unicast is well known Mike McBride: draft mentions multicast/unicast conversion, but at least mention the automatic conversion. Greg: Original root problem Charles: probably Aruba product. Maybe situation will clarify Mikael Abrahamson: document does not need to be perfect. We still have a problem and want to get work on solution - not all vendors do this. In general it’s not done Jake: make sure deployment problem is well written Toerless: maybe state: deployment problem is that users may not even know what the AP does for multicast, so results of multicast services are all over the place. Mikael: this meeting is recorded and shown on youtube. More recent comments: Move from SLAAC to DHCPv6 Mikael: Please do not put this suggestion into draft. Kyle Rose: disagrees. Would like to see this option, but mention security solution option. Mikael: Lets keep solutions out of this document Kyle: retract the suggestion Mike McrBride; there are some proposed workarounds from document. Toerless: taking out mentioning of workarounds is fine if we have plan for followup work to describe workarounds/solution. Warren Kumari: Maybe distinguish between operational workarounds and actual protocol/ implementation changes ? Mikahel: leave in mitigation techniques, document is in my opinion good to go. Jake Holland: Mitigation options. Sent text about AMT didn't see it in last draft. Charlie: You sent another email about changing your mind. Jake: Oops... maybe i change my mind again. Mention unicast-based service discovery (no comment about it). Next steps slide. Chair (Lenny): address last few comments, then send request for WGLC. Plan for next steps ? NIS working group ? Greg (Chair): We do not define solutions Toerless: AMT ? Lenny: We do transition solutions (AMT) and troubleshooting/operational tools (mtrace) but not routing/group membership protocols. Did anything change in IEEE since last time ? Charlie: not that i am aware of ? Charlie: We can make recommendations to IEEE as well. Mikahel: This is bigger than MBoned on solution side. We could go to IAB. Maybe use less multicast ? Assumption is to deploy into 10base2 network, but not working well over wifi ?! Someone needs to have strategic discussion where/how to proceed. Mike McBride: In agreement with Mikael. Maybe not wait for montreal. what to add ? Charlie: will not make the SLAAC suggestion given how contentious. Greg: changes seem to be fairly minor. See what discussion is on list. Charlie: Already prepared rev5, not posted, will fix up with comments from room, and then hopefully done. Quick show of hands, there is room support for draft. Lenny: rev it, request WGLC. Warren Kumari: I am an author, so will not progress the document myself, some other AD has to do it. ------ Multicast in the Data Center Overview draft-ietf-mboned-dc-deploy-05 Think it’s ready to be published. Included some forward looking things as ideas (SR with multicast etc.) Primarily practice and deployment document. Chairs: Who has read the documents, thinks is ready or last call ? Stig: What is intended status/purpose ? BCP/informational. Mike: informational (deployment) - not BCP. Stig: fine, future stuff wouldn't fit BCP. Jake: Typing up couple of editorial suggestions. Mike: will ask for WGCL within next few weeks. -------- Toerless 11:24 deprecating asm interdomain last rev- mostly editorial changes, clarified IGMPv3/MLDv2 support for SSM (not just ASM) wglc support in the room, uncontroversial, no comments will request WGLC -------- toerless 11:28 igmp questionnaire stig 11:34: clarify "features" stig 11:35: s/Implemented/deployed/ in #4 (toerless: ya, just missed global replace) stig: unicast for sending reports, RFCs require it toerless: implementors, not operators stig: watch for security concerns mikael 11:36: who can answer these? toerless: i2 is our usual, maybe ripe also? mikael: igmpv3/mldv2 support is different from (S,G) support, some STBs do not toerless+mikael: deployment issues also include applications, they use v3 but still join (*,G) mikael: got another weird hack that was technically (S,G) but not general case toerless: another application section in questionnaire mikael: is there another way to capture this and avoid repeating mistakes? lenny: joke meaning no. charlie 11:40: long questionnaire = few responses, so pick top 4 and focus toerless: hard to tighten this Mikael/Toerless: Add section about application support for SSM (not really a PIM WG issue, but important from MBoned): Does application only use "ASM" IGMPv3/MLDv2 signaling even if maybe the host stack supports IGMPv3/MLDv2 Also implemented only single source (S,G) -------- draft-jholland-mboned-driad-amt-discovery Jake: At Hackathon104 found out new issue, which will make me delay ask for WGLC until after this is resolved. Issue is limitation of one-hop mDNS discovery in home network (see slide for explanation). Toerless: In cable routers DHCP feature exist to propagate DHCP options from SP. Jake: generic workaround solution: DNS-SD propagation (via DNS-SD) will not work generically. Solution is to rely on anycast address Jake/toerlessL will take detail anycast discussion offline. Jake: next steps. Fix anycast/DNS-SD ordering, then WGLC. Mikael: Do you think it’s in pretty good shape ? Yes, except for anycast issue. Jake: Yes. -------- Lenny: Multicast to the Grandma (MTTG)- ubiquitous multicast Lenny showing multicast stream sourced on MBONE (I2) through AMT relay to Internet (IP-multicast + AMT tunnel) (high quality). Lenny: open source film under Creative Commons license, so no copyright laws are being violated Toerless: Customers often have >100 Mbps with VDSL now - higher quality atttractive but expensive in providing unicast. Jake: Some higher bitrate Slide Step 2 - AMT gateway implementation Jake: Do you know if gateways support L-flag (overload indication) ? No. Toerless: how to find relay ? Lenny: amt-relay.m2icast.net for relays (162.250.137.254,198.38.23.145). Do not like anycast, too vulnerable to DoS attack (announce non-gateway to blackhole traffic). Greg: Private anycast addresses ? Lenny: suspect in the future, Anycast will be critical- each provider to use its own any cast address, but no one will use the global any cast address. Broker service, DNS, ... Mikael- global anycast was a disaster with 6-to-4, so don’t use in the future Lenny: thanks for confirming my suspicion that it was a bad idea. Will keep not doing that! MikeM: Kudos for making this happen. Awesome. Mentioned solutions like youtube-tv to watch live sports. Any long-term thoughts ? Productizing this ? Lenny: hold the thought. Step 3: Multicast Content Portal (TV guide). Step 4: Offnet sourcing.