IETF 86 Orlando MBONED WG Tues, Mar 12, 201 3:20-4:50PM Boca 2 scribe: gorry@erg.abdn.ac.uk Audio archive: http://www.ietf.org/audio/ietf86/ietf86-boca2-20130312-1520-pm2.mp3 Jabber log: http://www.ietf.org/jabber/logs/mboned/2013-03-12.html The status of the WG items was reviewed. Updated charter and milestones have been submitted to IESG * AMT was submitted to the IESG, there were issued to be addressed. * Multrans Problem Statement Ron Bonica: I'm not sure who wants the PS. Joel: I do not know which items the WG should work on. If there are implementers, it would be good to know what they are working on. I would be fairly uncomfortable taking proposed work to the IESG with section 5 the way it currently is, and we do not have commitments to work on this. Lenny: There are people who want to work on this. Joel: Running code and running away would be really helpful to know about. An INFO document from an implementor that says they need the work would be valuable. I don't know such a document exists. I think this document should go to WGLC and people should then comment on the list and say what they think. Ron: When we asked the operator community, they said there is a way to deliver to IPv4 and IPv6 users: They could replicate the content - why do we need a more complex system? -: We want to understand how to deploy IPv6 in multicast with IPv4. Joel: Do you have a vendor that you are working with to implement this? -: Yes, we are working on 4-6-4 and 6-4-6. Ron: These are transit solutions, not 4 to 6 or 6 to 4? Greg Shepherd: Softwires has similar work. I describe 4-6-4 and 6-4-6 as transport methods, rather than transition mechanisms. -: 6-6-4 is also a case. We have v6-only receivers. Dino (via jabber): Note that terminology is different in different groups. Greg: There is unfortunate acronym re-use. Greg: Most systems that support v6 also support v4? -: No. Bill : The use case I was thinking of was an IPTV solution where set top boxes will not be updated, and are fed from a HFC network. It is not a possibility to simultaneously carry all traffic twice. Greg: This community is not well-represented in this room. Tina (via Jabber): There are use cases in the problem statement. Chairs: Please send drafts to define appropriate use-cases. The PS has been adopted and has been worked upon. The AD has suggested we should move to an early WGLC to understand the arguments and clarify things. It's not a guarantee that the document will advance. It may provoke questions and comments and a further WGLC may be needed. Please speak-up on the list, especially about section 5. Joel: If you are an implementor or a customer, please surface some information to help define what work mboned will be doing a year from now. Section 5 is a roadmap, let's understand if this should happen. SSMPING testers are required. Tim Chown noted there is a new version of the tool that reflects the draft - please contact Tim or the author. draft-tarapore-mboned-muticast-cdni Tarapore Lenny: Who has read the draft? <6> Lenny: How many in favour of adopting this? <5> The adoption decision will be taken on the list. Toerless: What about if there are more domains? Do you really want to constrain this to only 2 domains? Greg: This seems like a useful work to do to support the CDNI work. Tarapore: This is the simplest case. - Is this documentation of how CDNIs are using multicast, or what they plan to do in the future? Tarapore: Both documenting, and operational issues. Greg: I see merit in documenting this. Stig: Are we trying to describe all the uses? It would be good to also consider how AMT could be used in this context. Bob: I am not aware of providers working across peerings and we have good reasons to think this is useful. draft-ietf-moboned-auto-multicast-14 draft-shepherd-udp-multicast-guidelines Shepherd IESG discussions suggested that the WG consider EXP status for AMT, because there were things to be understood. The authors want to continue draft-ietf-moboned-auto-multicast-14 as standards track. Greg presented a need for draft-shepherd-udp-multicast-guidelines. Toerless: It is worthwhile to have a BCP document for multicast. Concerning AMT, I am not sure we need to care about congestion control in a tunneling mechanism. This is not required for other tunnels. Greg: There needs to be a deployment case for this. Gorry: Some RMT methods require feedback that isn't talked about in AMT, which is unidirectional. Greg: You can still do feedback, but we didn't write this. Gorry: GRE has been used to tunnel multicast for a long time, and we have experience. Greg: Other tunnels also carry multicast, e.g. LISP. Dino (via jabber): LISP does multicast but this is not tunnelling. Greg: AMT is receiver-driven, there is an RPF so some problems are better protected than for unicast. Toerless: We are conflating two issues. What is the state of the art for CC in multicast? The AMT discussion is something else. Joel: An IESG "discuss" is a way to work through the issues. The new document is useful. Gorry: I'm not sure IPTV is multicast, it's a provider network solution. IPTV, Often sending at constant rate also have an interest in knowing if there customers get loss-less service - so there are operational tools to ensure that networks do not beak. Joel: A difference here is that traditional multicast trees were built between people who understand multicast, and this is not the case for AMT. Greg: We could take draft-shepherd-udp-multicast-guidelines to TSVWG. There is no Agenda time this IETF. Gorry: As TSVWG Co-Chair, this document appears to fall within the charter of TSVWG, I would encourage you to take it there and ask for adoption. There is no agenda time this IETF, but we will do heads-up announcement that the draft exists. Who has read the Guidelines I-D? <7> draft-boucadair-6man-multicast-addr-arch-update Stig Venaas Tim: This seems useful to do. It may be worth clarifying the way in which the flags fields are inherited. Stig: I think it is useful to know if they are bit flags or a field. Tim: I think they are bit flags. draft-zhou-mboned-multrans-path-optimization Zhou Ron: There was a criticism that this work starts on the basis of a problem statement that has yet to be agreed. Joel: I am happy to see discussion on this document. Ron: After we make a decision on mast PS, then we decide if this is useful to adopt. Stig: I think we need more than to agree the problem, we need to determine to work on translation and then see optimisation. Keep this document around, it may be a useful future input. The authors noted that they would like to see the PS and optimisation should work in parallel. Joel: This is not yet an adopted WG document. I think it is also not a stand-alone document, so we need to consider this after we have decided what to do next. Chairs: The next stage is to determine the use cases, and then decide if there is need to write a companion document that could sit alongside this. draft-wang-mboned-glo-ipv6-mcast-reachability Meng Toerless: Is this inter or intra-domain? -: There is another draft on this problem also seeking work on multicast VPN. It would be good to see proposals discussed in the same place. Ron: If this draft defines a new NLRI does it go beyond mboned? Joel: I think this belongs in the INT area. Please take discussions to the list, and we should discuss there. On Friday there are simultaneous presentations on multicast in LISP in PIM and LISP. End.