Minutes for NVO3 at interim-2015-nvo3-3
minutes-interim-2015-nvo3-3-1

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 <anoop@alumni.duke.edu>
- 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 <lucy.yong@huawei.com>

- 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 <sarikaya2012@gmail.com>
- 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.