IETF 90 Toronto MBONED Meeting Mins Thurs, Jul 24, 2014 9-11:30AM Manitoba Note Taker: Percy Terapore Audio log: http://www.ietf.org/audio/ietf90/ietf90-manitoba-20140724-0900-am1.mp3 Jabber log: http://www.ietf.org/jabber/logs/mboned/2014-07-24.html 1. Chairs: Lenny a. Note Well b. Status of Agenda c. Status of Active WG Docs: i. Geo-distribution: JeffreyZhang- need to address some comments received from Toerless ii. Multrans - Quiet so far iii. Data Center - Mike to talk about this. iv. Mtracev2 Also some comments received and perhaps this is ready for last call (Lenny)? Pretty extensive revisions from IESG so another round of changes needed before WG Last Call. Lenny: Make changes and ask for comments from list & then make ready for Last Call. d. AMT Update: i. In IESG for long time with lots of comments. ii. Joel - One issue to resolve: concerns about selection of algorithms by Security area; Do need to do to explain to them. iii. Lenny - Need to get original authors to clarify? iv. Joel - Yes that would be good. Need to be gentle but firm to point out history. v. Lenny - what if original authors do not remember history? vi. Joel - It could be worked out as the Transport problem was worked out in same way with Security. Issue is with preventing people from injecting their own signaling. Needs to be resolved. vii. Lenny - will work to contact original authors 2. Multicast cdni - Percy a. 6th version b. Need to change title draft-ietf-mboned-multicast version 0.0 c. PT- started Vancouver 2012 d. New are i. Provisioning Guidelines ii. Gap we need to develop draft on optimal AMT iii. Billing guidelines iv. Logging Guidelines (usage logs, security logs, other logs: access, app, syslpog) v. Settlement Guidelines (aggregation, collection, transport, billing and reimbursement) e. Next Steps i. Complete section 4 ii. Comments iii. Goal complete by 1Q15 f. Comments questions i. How is this different from unicast (it covers the specifics of multicast with respect to ADs)? Look at CDNI WG work to perhaps point to as appropriate. 3. Multicast in Data Center (MikeMcBride): a. Per Charter: Create practice documents for various multicast experiences. b. Joel: OK as part of charter c. Motivation : Emails opinions on use of multicast in DCs?: i. Document multicast use in DC as part of MBONE work ii. Goal: Find unique aspects of Multicast use in DCs & describe here. d. Multicast Apps used in DCs: i. Windows Media servers ii. Publish iii. Marjet iv. IPTV v. VRRP vi. Overlays vii. Etc: viii. How are they being used & do they scale well? e. Challenges: i. Broadcasts when igmp snooping ii. VRRP chatty heartbeats iii. Overlay iv. VM Scaling v. Others? f. Request for MBONE: i. Seeking co-author & feedback g. Percy: Data Centers moving to NFV/VNF environment. How does Multicast use fit in with NFV? h. Gorry: consider WAN use in DC for Multicast? i. Hitoshi: Do we need to address WAN area here? j. Gorry: Given virtualization, yes this makes sense k. Hitoshi: Goal could be providing guideline so maybe look at the revived draft again to clarify? Specifically for IPv6 issues l. Gorry & Joel: Scaling issues may not exist for this topic. So MBONE can offer useful advice on scaling properties?? Taking into account sensitivity of application - find list of do's & don'ts!! m. Gorry: Not multicast problem per se; rather use of multicast is one way to resolve the issue!! Joel agrees. n. Mike to update I-D 4. Traceroute for MVPNs (Bob Kebler): a. Current Version description - where Mtrace does not work (list shown) b. Lenny: Does GTM have same problem?? c. Robert: Yes i. What Mtrace can do (description of what is new) ii. Error Conditions iii. Next Steps - will revise draft to address extensive comments from Eric Rosen, then seek WG Adoption d. Hitoshi - Meaning of Augmented Response blocks?? e. Robert - additional info than standard response blocks; additional clarifications between Hitoshi & Robert. No desire to change Mtrace v2. f. Lenny - Which WG is appropriate? Would other L3VPN WG be comfortable with this in MBONE? Robert ? Yes g. Lenny - Merging this into existing Mtrace I-D or start new work? Robert - leave current I-D alone & start new one 5. Multicast Receiver Access Control (Bill Atwood): a. Trust Relationships (Unicast & Multicast) b. Use NSP Representative Model c. Assumptions d. Problem Size - NSP & EU interaction e. App Level & Network Level interactions f. Two Solutions described g. IGMP drafts could not address this issue h. Securing IGMP/MLD i. Goals: List requirements for SPs to interact with CPs & Specify architecture j. Requirements list for application constraints & interaction constraints k. Building blocks - use IETF protocols l. Architecture & Environment & Enforcement Points ? Results m. Four Documents issued with more to come; request for liaison to PIM WG on this n. Mike - Why liaison? Bill - Need clarification from PIM WG for permission to proceed. Joel - this is not a formal liaison; just interaction needed between WGs. Toerless - Good to get PIM opinion & need more Use Cases to motivate this work. o. Stig - how easy to deploy this? Would it be used widely? Bill - could be used at any level including households. 6. Lenny - Open Discussion: a. Stig: i. Changes in Routing Area may impact Multicast ii. PIM & MBONE have similar work & common participants but WGs are in different areas. So maybe have PIM & MBONE have a shared 2.5 hour session. Lenny - this is great idea as strong overlap. But time may be issue as not all sessions may be done in 2.5 hours. Joel - Good idea to do this; allows more coordinated activity. Mike - Supports this idea. Question on MULTRANS status? Lenny - interest waning on MULTRANS; no strong consensus on how to develop problem statement. No major interest. Joel - many use cases but not enough business support behind them; hence not compelling enough to advance work. Tina - thinks there may be business cases to justify from some SPs. Joel - still not sufficient motivation. Tina - wants to know about details as to why no interest. Lenny - there was discussion on this with not much support for moving forward. Tina - what about problem statement itself. Lenny - discussions on Toerless' solution proposal seemed to make problem statement moot. Suggest to bring this up again on the list and see what responses received. Joel - no broad consensus to advance this from February 2013 discussions. Lenny - bring this up again on mailing list with Toerless proposal. Mike - similar question; what is status of Multimob. Lenny - moved to separate WG. Joel - Multimob is being used in industry. Stig - have more generic problem statements & then think as to how to advance work. iii. Lenny - Interest in Internet Multicast seems to be at an all time low, yet the need is arguably greater than ever. And the tools are finally available in production to solve the most long-standing problems (i.e., AMT). How to jumpstart interest in Internet Mcast again? World Mcast Day? Toerless - Can we bring in all our ideas in and discuss what best way to proceed? How widely is Internet Multicast being used right now? Can we get marketing info to justify work? Joel - AMT can build Multicast over Unicast; can characterize what happened in MBONE and see what role it plays in this "Getting right" topology resulted in lost participants. Experiments are easy (IETF) but implementation is hard. So MBONE should move forward accordingly. Stig - last mile may be an issue?? Joel - if we provide right technology, content delivery will take care of itself. Stig - cases in Europe where millions watch events but maybe not on Internet. Toerless - find pool of folks providing AMT capacity and then provide experiment to deliver content?? Engage MANET besides MBONE?? 7. Lenny - Meeting Adjourned!!