Re: [MBONED] MBONED mins from Prague

[Tim Chown <[e-mail]>]

Hi,

The notes from the acg-mboned-multicast-models-00 discussion look good, and useful for the draft rev, thanks!

Tim 

> On 25 Jul 2017, at 15:16, Leonard Giuliano <[e-mail]> wrote:
> 
> 
> 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.
> 
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
>