[MBONED] MBONED mins from Prague

[Leonard Giuliano <[e-mail]>]

Draft mins from MBONED last week are posted at 
https://www.ietf.org/proceedings/99/minutes/minutes-99-mboned-00.txt and 
pasted below.  Please take a look now while it's relatively fresh on the 
mind and speak up if you see anything that should be corrected.

And a big thanks to MikeM for taking such excellent notes.


****

IETF 99 Prague
MBONED Agenda
Tues, Jul 18, 2017
9:30AM-12PM
Athens/Barcelona (Held jointly with PIM WG)

Note takers: Mike McBride

Jabber Log: https://www.ietf.org/jabber/logs/mboned/2017-07-18.html
Audio log: 
https://ietf.org/audio/ietf99/ietf99-athens_barcelona-20170718-0930.mp3
Video log: https://www.youtube.com/watch?v=JYCJD_F9b1g

Status of WG items Chairs, 5 min
draft-acg-mboned-multicast-models-00 Chown, 15 min
draft-ietf-mboned-mtrace-v2-17 Asaeda, 5 min
AMT Hackathon Update Holland, 15 min

wg overview:
mtrace draft went wglc last year. one comment from stig so far. need more 
comments
Tim is shepherd for interdomain-peering draft. several nits, all textual. 
authors to fix nits, rev and will be submitted to iesg.

acg-mboned-multicast-models-00 Tim Chown
Discussed in Berlin. Original purpose to document mcast service models at 
high level.
Discuss their use cases; document deployment examples
Recommend use of ssm
got some feedback at ietf96, some interest in the draft
strip back on the text of service models
need to have a draft which promotes use of SSM
refocus draft on positive use cases of SSM
give an appropriate new title
What about ASM?
interesting proposal by david farmer on internet 2 mcast lits:
https://lists.internet2.edu/sympa/arc/wg-multicast/2017-06/msg00001.html
where they deprecate use of ASM on internet2 and eliminating MSDP.
Do we want to take IETF action here?
Is it just about making backbone simpler to operate?
We can make our draft a BCP for SSM use
What about ipv6? embedded rp isn't too hard to support but should we make 
rfc2956 historic as well, leaving just ssm for ipv4 and ipv6
What about bidir PIM?
What about IGMP/MLD?
-rfc6434bis makes MLDv2 support a MUST
-should also make a statement about igmpv3
How to understand which apps use ASM vs SSM?
What do we actually want to do?

Stig: we should encourage ssm but not deprecate ASM. There are cases 
intradomain use cases for ASM for source discovery. especially link local 
and site local multicast. finding dhcp server. customer apps from various 
vendors. light bulbs. There are cases where its hard to use SSM and we 
should capture those in the drafts. people using embedded rp for multiple 
domains within one organization. likes idea of discussing different models 
but say this is for this specific purpose. Should not use ASM. SSM is more 
secure, easier to manage, etc.

Jake: RFC 4609 informational security makes a recommendation about not 
using ASM. may want to reference it.

Tim: pull statements from various RFCs and reference into this doc.

Mikael abrams: doing interdomain asm is brittle. he wants to help people 
in their organizations to make the case about moving to SSM. Give them 
guidance to choose a different solution.

Lenny: we as a wg can provide direction to app developers. we should have 
made a stronger point about SSM years ago. Many SSM unaware applications. 
Give clear direction. You shouldn't do this. make a stronger statement.

Stig: Good doc. we need something like. app vendors the network and host 
stacks support igmpv2 today. hard to go to app vendors to say you need to 
change your application.

Nihlen: more for deprecate. shutting down. would make his life easier. 
interdomain deprecation.

Tim: what does that mean, and how to express in document.

Greg: we don't have a police to enforce. we make a decision and hope 
people use it. Been harping on no ASM in interdomain since 2003. if there 
are apps that require it lets hear about it. really only walled garden 
apps need ASM.

Sandy: MSDP is widely used in China. SSM as important but do not killed 
embedded rp. recommended is better.

Stig: thinking about it more, might support deprecating MSDP.

Mike: emerging technologies like artificial reality/virtual reality 
(AR/VR) are considering the use of ip mcast. It could explode with IoT. 
Now is the time for ietf to draw a line in the sand with ASM/SSM 
recommendation.

Nils: DT has big deployments of ASM. since moving to SSM the operations 
dept has a much more stable network. we support deprecation. used ASM 
because applications. its igmpv3 that new set top box supports, no need 
for ASM anymore.

Tim: SSM mapping could be used

Mikael: this doc gives you another hammer for set top box vendors

Toerless: we failed on this. when vendors say their STB supports v3 you 
still have to use it.

Stig: should mention ssm mapping. you want to send *,g but need source 
discovery mechanism.

Mikael: one vendor had a config file where you config the 'S'. you could 
not have ssm with two different sources, could only have one. they did ssm 
mapping in the set top box.

Toerless: instead of having a draft about ssm mapping the draft should be 
where do source addresses come from.

Lenny: by show of hands who would be in favor of the draft saying having 
strong recommendations using ssm vs asm interdomain? split 8 for strong 
recommendation and 7 for deprecation. roughly 50/50.


Hitoshi: mtrace-v2-17 draft
changes from 15 to 16:
revised the introduction to clarify the criteria for directing the mtrace 
v2 query to either a last hop router or a RP.
scanned for and corrected deviations from conventions, description of 
field ranges, etc
broadened the description of circumstances in which a reply may be sent 
before the mtrace reaches the FHR.
expanded on the criteria described in section 3 for validating TLvs within 
the message and for handling invalid TLVs.
corrected the minimum length requirement in section 3.
In the forwarding code item in section 3, added an explicit definition of 
the reserved error code range.
section 4.5 corrected the description for the number of hops field 
adjustment made when proxying an mtrace v2 query.
added more specific details and wording corrections to the descriptions of 
the mtrace2 forwarding codes registry and TLV types registry in section 
8.1 and 8.2.
Formula for converting from a UNIX timeval to a 32 bit NTP timestamp for 
Query arrival time (because POSIX.1-2008 recommends clock_gettime()

Lenny: this draft was submitted to IESG several years ago. Kicked back. 
2nd WGLC. First one was last year. Need comments from WG. Mention whether 
you do or do not support advancement.

Stig: Really important. taking too long. There are implementations of 
this.

Lenny: would anyone be interested in document shepherding this? crickets.


Jake Multicast over SPRING @hackathon report
Worked on AMT implementation. Extended it with v6 support.
AMT+mcproxy Implementation Update
Plusses:
-IPv6 support added (gateway and relay)
-etc
Hackathon requirement:
-Native multicast over CMTS without PIM upstream. Insert reasons from John 
here.
Solution:
dump data packets from relay raw with a shim (instead of forwarding 
AMT-encapsulated).
-IP lookup for configured SRH shim
-send once per SRH (shared across gateways).
-do multiple gateways with source filtering
Greg: where does the association come from?
Greg: static or DNS
Jake: It was hard wired in this demo. publishing a recipe on how to 
connect to their traffic. If we could do AMT over DNS that would make it 
easy.
Toerless: Is there an AMT IGMP join sent from AMT gateway in the home 
router?
Jake: Yes. the home router running mcp proxy with amt gateway. Homer 
router configured to understand which gateway to talk to.
Toerless: must be a trick on how relay to know how igmp joins on the same 
downstream would only need to be sent as one copy.
Jake: that was the effort.
Toerless: how to identify which home routers
Jake: look up table. have remote ip address from gateway
Toerless: not sure if its operationally feasible to create a table. like 
option 82. then can get rid of table. seems like lightweight work is 
possible for cable modem. minimize admin work on gateway.
Jake: If John had wanted a different lookup it would have been fine. we do 
it once for destination.
Jake: this is a network specific implementation
Toerless: encourage people to look for a better non hacky answer. you can 
still bring bier in. terminate bier one hop before cmts. what about rest 
of distribution network.
Jake:
AMT project: useful next steps
conformance test suite (packetdrill, fuzzing)
Gateway source-filtering (+permite multiple gw instances)
pimd support
automated CI
high performance forwarding path
package for distros
deployable containers
progress as time permits
volunteers very welcome

wifi multicast discussion
Mike: we have a draft in mboned on wifi multicast that needs updating. We 
created it because so many questions about why multicast is bad over 
802.11. No reliability, high PER, no acks, people just convert mcast to 
unicast at the AP and be done with it. Alvaro attended a meeting on this 
on Saturday and perhaps he can give us an update. Either way, mboned 
should provide this use case to the community on our take on the problem.
Alvaro: instead of waiting for ieee in 6lopan they changed neighbor 
discover for v6 to change some of the broadcast. perhaps they help not 
just for iot. there are some specific things we know don't work. about 20% 
of the time it doesn't work over wireless. we need to coordinate better 
between 802 and ietf. we are at an impass. we have a problem statement in 
mboned. we have a considerations doc in internet area. we should now work 
on solutions. understand how radio works and things we need to do. he will 
encourage people here at ietf this week to meet to discuss on the side 
(which he did).
Carlos: we presented last ietf. intarea experimental work on 11ae. willing 
to work on testbed.
Alvaro: send to him. maybe he can set something up
Jake: were there a list of solutions?
Alvaro: no. couple of drafts that looking at. good to get more feedback.
Carlos: we need to look at the interarea document.
Mike: will update the document and attend the side meeting.