IETF 92 Dallas MBONED Minutes Tues, Mar 24, 2015 1-3PM Continental Note Taker: Duke Fischer Audio log: http://www.ietf.org/audio/ietf92/ietf92-continental-20150324-1300-pm1.mp3 Jabber log: http://www.ietf.org/jabber/logs/mboned/2015-03-24.html Agenda begins: Status of Active WG Docs RFC7450 Greg B, finally made to RFC status after 14 years Percy Tarapore presented : (draft-tarapore-mboned-multicast-cdni) Percy would like to know if name should be changes, what version, need guidance o Lenny recommend name change and version to start at zero Lenny questioned relevance of AMT tunnel (section 3) Percy ask for thoughts where 2 domains my not utilize same protocols (section 4.2) o From audience 1st recommendation is to put into separate document 2nd recommendation is to state in document that this will not be addressed 3rd recommendation is if there is a consensus that this is not a good idea, then do not put into document. Do not need to include every corner case/crazy idea a SP might have. (there were other comments, but they fit into the same as above) Asking for overall feedback (section 4.3) Lenny: what about ASM? Specifically, should MSDP be mentioned since it has been used for peering in the past? Consensus: No, should focus on SSM only for interdomain and not document ASM since it is not recommended. o Lenny this document is basically for peering, could we use unicast peering guidelines as a template. Asked audience if anyone knows of one. Audience: Nothing known, but believe there should be docs somewhere, and will look o Comments on not covering settlement, to keep the document shorter, more focused o Comment on need of this document. Is there a need for mcast peering between providers? We tried several years to get global multicast to work and failed. o Can we add section on troubleshooting and diagnostics o Percy summarized that this section should be condensed, but also add troubleshooting piece o Lenny would like to get more operator input Ali Begin presented (draft-singer-appsawg-mcast-url-00) o Lenny asked why fcast Ali asked for general questions: Is there a need for this, do you care or not care? o Can background on how these are URLs are used in unicast? To provide an example, would be helpful o How do notify the clients to switch to multicast Redirect to a different URL to join multicast stream Should be done in real time without prior signaling o FCAST would like to be used since it is being adopted by much of industry o Could you bring aspects of AMT into this also? Lenny polled room on who has read the draft? o None, but this has not been sent to MBONED working group o Please troll the WG before submitted Poll on who thinks should be MBONED working group o ~ 7-8 support adoption, 0 against Bill Atwood presented (Secure and Accountable AMT) General questions at the end o Was any of the security issues addressed with AMT? Comment that the security issues have been verified. Bill said he will provide additional information on the list Lenny presented (Multicast Requirements for 2015) Some comments from audience: o Bursty sources not sure if the requirement should be removed Do we want one solution to that covers everything: Question of discovery of sources Do we want the network to do the discovery or the application o Separation of control and data to keep to improve multicast o The network already has unicast capability to everyone, why do I need to complicate it with multicast? Belief that live linear is not dead, there is a need for multicast in the future, with future applications? o The question is how much do you want to do? Just how large of scope do you cover? If this WG could provide useful guidance to app developers, that would be great. The other questions is would it even matter o There was a ton of comments and feedback here too many to document Greg Shepherd BIER update Best draft to start reading is the problem statement, then architecture If there is a solution in IPv6 please bring to the group