Minutes IETF99: mboned
minutes-99-mboned-00

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.