Minutes IETF103: mboned
minutes-103-mboned-01

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.