Minutes IETF104: mboned
minutes-104-mboned-00

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.