IETF NVO3 WG Virtual Interim Meeting Minutes 2015-02-12 11:30-13:00 EST Chairs: Benson Schliesser, Matthew Bocci Secretary: Sam Aldrin Topic: Overlay Multicast (over, under, etc) 1. Meeting Introduction and Agenda Bashing (10 min) Chairs - This is IETF activity and note well applies. Please read if you are not familiar with it. - Will use virtual blue sheet. Everyone please signin - Any Agenda bashing? None. So let us get into presentations. 2. Multicast Framework Considerations (20 min) https://tools.ietf.org/html/draft-ghanwani-nvo3-app-mcast-framework Anoop Ghanwani - This draft s application specific multicast. Initially it was just multicast specific issues. - This draft documents each of the multicast mechanisms and discuss impact on applications. - There are ARP/ND and (S,G) (*,G) traffic Erik>Multicast DNS networks and DHCP are other type of multicast traffic, not talked about here. No multicast case: - Use NVA to obtain end station info. - NVE responds to ARP requests from TS. - No support for applications. - In the case of control plane impact, NVE need to be configured for ARP handling and no need of L2 learning For replication at the source: - Network need not be multicast enabled. - Copies are delivered by unicast. - For control plane impact, NVA must be configure NVE with all the addresses. Address learning may be used. Replication at Multicast service node case: - MRN is the one which creates copies - Underlying network need not be multicast capable. - The MRN could be scaled out to overcome forwarding performance - Typical bridge learning doesnÕt work as IP address gets changed at MRN - In the control plane impact, unknown traffic is sent to MRSN in addition to TS IP multicast in the underlay: Benson> Sending different multicast address is a requirement? Anoop> No it is not a requirement. Could live with suboptimal delivery Lucy> Any VM could be the source? Anoop> Yes. - Control plane issues Š NVA configure NVE on which group address to use which VNI - Summary Š There are many ways to achieve multicast transport. Pro and cons are discussed. - This document is around for a while and would like to have it become WG. Benson> Personal view is that it make sense to have a doc describing various multicast methods. Benson> Authors pls do write an email soliciting comments Lucy> IT is useful and should be adopted as WG doc Bechet is not on line. Will move up LucyÕs presentation. 3. IGP-based Multicast (10 min) https://tools.ietf.org/html/draft-yong-rtgwg-igp-multicast-arch Lucy yong - More people will be working on this doc. - Trend is to separate network IP space from service IP space, where network IP space is underlay. - Once decoupled, no need to of underlay manual configuration - IGP does not support multicast network yet. - Support IP multicast in IGP - Use single IGP to support unicast and multicast packet delivery - IGP is used to announce tree root - Each multicast group is associated to atleast one distribution tree - Pruned tree is based on edge router membership on a multicast group - Tenant multicast traffic could be L3 or L2 bum traffic - Tenant multicast receivers send or replt over IGMP /MLD for joining or leaving - NVo3 is the primary use case for IGP multicast Alia> We are still working on renaming. - Moving forward, this work will be in that WG. - IS-IS and OSPF extensions for IGP multicast - Using PIM has advantage to use in this scenario and also has issue with convergence time. Bhumip> Put a question in the chat window. What is the role of NVA in this? Lucy> We are talking about underlay. NVA is transparent to underlay. However, the mapping is done from overlay to underlay. Other than that there is no relation. Lucy> Will the PIM group will be renamed and new charter will be developed? Alia> I am looking to see what to do. Renaming is not imp, but looking to re-charter. 4. VXLAN Multicast (10 min) https://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast Behcet Sarikaya - I changed the title of the draft - Deals with two things, One is for tenant identifier and other is multicast mechanism. - How to deliver ARP to nodes? - NVE needs to get tenant ID or VXLAN network identifier - Talked about address resolution challenges - We presented this draft last year. Got feedback from DHCP chairs and incorporated them. Benson> Would like to see more discussion about this approach. Behcet> This sort of mechanism is already being used. This will make standard option Anoop> Why canÕt NVE get info from NVA? Why bring DHCP server? Behcet> We could mention NVE could also be used. Benson> chair hat off Š This mechanism takes the role of NVA; chair hat on Š need to see which option is better. Benson> We need to have more mailing list question. Benson> Forgot to start recording the session. Hopefully notes has captured all the points. 5. Open Discussion (40 min) Behcet> VM mobility draft was updated. So, what should we do to get more feedback Benson> Let us talk about that on the mailing list. Want to keep the discussion to multicast. Erik> How about other traffic types like DNS etc Benson> ARP and ND is quite clear. But for mDNS, it is not so clear. Would like to see that discussed. Anoop> Will sync up offline with Erik Lucy> IÕd like to solicit feedback for IGP multicast network. Benson> Good to send email, but do not think NVo3 should take up that work.