Mboned Status PagesMBONE Deployment (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 1996-Aug-26 —Chairs:
IETF-103 mboned minutes
Session 2018-11-06 1610-1810: Boromphimarn 3 - Audio stream - mboned chatroom
IETF 103 Bangkok MBONED Minutes Tues, Nov 6, 2018 4:10PM-6:10PM Boromphimarn 3 Etherpad notes: https://etherpad.tools.ietf.org/p/notes-ietf-103-mboned Jabber Log: https://www.ietf.org/jabber/logs/mboned/2018-11-06.html Audio log (audio starts at 6:15): https://ietf.org/audio/ietf103/ietf103-boromphimarn3-20181106-1610.mp3 Video log (audio starts at 8:30): https://www.youtube.com/watch?v=bCy7j-DoGGc Note taker: some sucker… 16:18 note well 16:20, sucker agrees to take minutes 16:20 no objections to agenda toerless: draft-ietf-mboned-deprecate-interdomain-asm - jake, re ssm addresses only: glop also allows ssm, according to address owner's disposition. - toerless: yes, but how do you get the other routers to treat it one way or another? anyway, recommending ssm addresses only. - greg: when was latest rev? - toerless: 2 weeks ago - greg: how ready is it? - t: pretty close, just discuss addressing stuff maybe - greg: let's last call, light a fire? - t and michael: ok mankamana: MVPN Mtrace - existing draft for mvpn mtrace from ietf 90. revisit in light of new mtracev2 - (i think it's: draft-kebler-kurapati-l3vpn-mvpn-mtrace-02 ) any other tunnels? - stig: yes, bier is interesting, could be useful - jake: amt also would be nice charlie: draft-ietf-mboned-ieee802-mcast-problems (time permitting: would like to go over some review comments) - comment 1: wifi vs. Wi-Fi? - kathy: it's Wi-Fi(tm) first use, then Wi-Fi - comment 2: toerless some rfcs referenced - comment 3: dual stack comments, maybe recommend picking one? - mikhael: no, don't do that. - mikhael: ieee was asked, said "that's the way it is" regarding wi-fi multicast. Should ietf say "ok" and cut down multicast usage? Is this a conclusion? - charlie: thanks, good question. standards to handle it not deployed. - mikhael: ok, so that means we really should cut down on multicast? - strong word. maybe proxies, as described by some rfcs that do a sort of unicast registration protocol - mikhael: if wifi won't solve multicast, on layer 2, from the top of ietf, for wifi layer 2 ietf side we just stop doing multicast, period. as much as possible. protocols today just run the same. if the conclusion is no, multicast will never change, then transport, iab, wifi the answer is layer 2 is no multicast. charlie: not quite, many routers sending wired packets, most stuff doesn't need to change mikhael: but service discovery, arp, broadcast, all of it needs to stop doing multicast instead of unicast mike: stig: ipv6 neighbor discovery. will equipment do special tricks to make it work? you can't really extend neighbor discovery. mikhael: they do this for v4 already. mikhael: fully support this draft - greg: is this ready for wglc? - charlie: after this - ok, we'll send to list - jake: after responding to reviewer comments? - charlie: jake's comments good, except maybe amt - jake: as part of solution, not problem - oh, ok. yes. - charlie: wglc after rev to address comments please, will submit within 2 weeks mike: draft-ietf-mboned-dc-deploy - jake: draft-jholland-mboned-driad-dns-relay-discovery - 1 read it, 2 support adoption (3rd agrees it sounds interesting) mikhael: comments - there's a hackathon project deployed for what he's doing. v4 to v6 multicast something - it's just plug together standard stuff that exists already, and it sends packets and works fine - jake: hackathon was same way, btw.