IETF 94 NVO3 Minutes: 13:00 - 15:00, Tuesday November 3rd 2015 ------------------- Chairs: Benson Schliesser & Matthew Bocci Secretary: Sam Aldrin Note Takers: Ignas and Sam 1. Welcome/WG Status - Chairs (15 mins) Benson giving overview of WG and document status and plans.  - Read Notewell. Rules of IETF apply - Sign Blue Sheets - Sam and Ignas are taking notes - There is virtual queue and we are trying out. - Milestones haven’t changed. - 3 dP drafts adopted. - Control plane discussion is going on. - OAM DT is being formed. Meet chairs right after the meeting. - Planning/considering an in-person interim meeting, along with NANOG. - Try to do inter-op at the NANOG. Please contact chairs about this. We will update soon. - We couldn’t complete LC on Security Requirements draft. Will be closing it soon. - Goal is to LC use case and arch drafts. - Split NVE has resumed in liaison with IEEE. Lucy has presentation on this. - Nothing in RFC editor;s Q. Any Questions? None. 2. Linda Dunbar - NVA-NVE mapping control plane draft   (10 mins)
 - Was discussed in several meetings. - In last meeting, was asked to remove ISIS portion. - This draft now mainly talks about data model. - When VM moves from location to location, there will be small set of changes. - This draft advocate only incremental changes instead of complete dump. - In push model, NVA has all the info of inner and outer header. - There could be multiple instances responsible to different sets VN’s. - When VM moves, participating VN change as well. - In NVE doesn’t find matching, what should it do. So, this policy should be sent down from NVA. - We could use bitmap or range to announce the list of VN’s participating. - In the incremental update, the data model indicates that push is complete. - The Address family indicates which these VN’s belong to. - Data model is put for pull model to support query. - When the mapping is not available, should it flood or drop? - In hybrid pull and push model, push could be used for small set of VNs. - We are hoping for WG adoption. Q&A:      Matthew: who has read the draft?  3. Dapeng Liu - vxlan path detection 
 (10 mins)
 - This is PD in VXLAN. - This based on Controller architecture. - We collect from centralized location. = There is a reserved bit, indicating OAM packet. - If the bit is set it will process and makes a copy of the packet. - We already implemented. - Introduced authentication TLV. - Updated security section to address comments. Q&A:       Erik Nordmark/Arista: Do you support this for multicast? Even for unicast this can result in multiple responses for one single request. IP OAM mechanisms typically work on the model of single request and single response.  Dapeng: comparing this with traceroute this mechanism is simpler.  Deepak Kumar: this is targeted for validation of DC topology. Number of paths is high and therefore anything non-hardware based is not applicable.  Sam Aldrin: I do not like the idea - if you are controlling your own network, efficiency is not an issue. You will end up with a flood of packets with this approach.  Deepak: There is one packet going out to the network, responses return via different path.  Sam: I have mentioned this case as well. With one packet you are making every router in the path to respond, and there is no way to mute the intermediate nodes from responding.  Deepak: This is policy based. You will need to provide resources for this to work. This is for bootstrap time, and in the controller environment.  Sam: you are specifying this for generic VXLAN. Greg: I think the situation here is - we have an answer, but what is the question.  Erik: We can do better at managing the assignment of reserved bits - layer transcending traceroute has the same bits allocated. Matthew: we do not have a registry yet.  Pat Thaler: is it assumed that there are direct links to the controller? I do not think that this scales. This will use substantial amount of bandwidth. That does not seem to be an usable assumption, especially during topology changes. Dapeng: our solution is specific to DC scenario, that is the basic assumption of the model. Operator can control the devices in this architecture.  Pat: the DCs that target NVO3 architecture are large - you cannot expect the situation where every ToR has a direct path to the controller.  Dapeng: it is one packet only. Deepak: in this scenario this was used for 2 seconds and then quiet again.  Erik: We do protocols for internet - it says IETF on the document. Successful protocols get out of the initial environment, and may run over the whole network.  Dapeng: our solution has specific requirement.  Shahram: how are L3 devices supposed to detect the OAM packets?  Dapeng: They will recognize the VXLAN packet.  Shahram: routers in the middle do not know what VXLAN is.  Benson: please continue on the list.  4. Santosh Pallagatti - BFD vxlan 
 (10 mins)
 Greg Mirsky presenting. Q&A:      Benson: I think this is the draft that BFD chairs mentioned and it will be adopted in BFD group? Greg: this draft brings nothing new to BFD, it is more of the applicability of BFD in NVO3 environment.  Erik Nordmark: I think this is useful to define. Does this match with the work done on OVSDB? Greg: Not aware of that, please send pointers.  Deepak: Why do you need VNI 0? You can use TTL of 1, and that will also stop leaking.  Greg: in IP we do not have up and down MEP, and we would like to behave as an up MEP.  Deepak: in DC it should follow the exact path.  Greg: there is no guarantee that it follows the exact path.  Deepak: we can verify that underlay is operational.  Greg: we can verify the existence of the exact path in the underlay.  5. Fangwei Hu - vxlan YANG 
 (10 mins)
 Fangwei presenting.  - It is necessary to define YANG model for VXLAN. - Supports several access types. - In 1:1, VXLAN mapped to 1 LAN - in N:1, i VXLAN ID is mapped to several VLAN ID’s. David Black: What is the scope of single and multiple VLAN scopes - are those for single VTEP, or for multiple.  Fangwei: that is configuration aspect.  Erik Nordmark: it would be good to describe the rationale for all of this. It seems to be the same semantics as one to one mapping. All the packets get encapsulated without any inner VLAN tag. Fangwei: we can discuss offline.  Erik Nordmark: you mentioned IPv4 addressing - what about IPv6 support in the model?  Fagwei: yes, that needs to be covered.  6. Ting Ao - VNTP protocol 
 - (10 mins) Ting presenting.  Q&A:       Benson: I will note that VNTP and earlier presentation are bot interesting from the control plane protocol perspective - please discuss on the list.  7. Lucy Yong / Yizhou - VLAN config considerations in split-NVE (10 mins)
 Lucy presenting.  - This is CP work going on at IEEE - Split NVE means NVE is not co-located with VM - Even if VM is on same server, traffic has to go through external NVE. - Option1- VLAN ID per VM - option 2- Primary VLAN and Secondary VLAN Lucy: A comment - this draft is a recommendation for configuration in split NVE environment.  Q&A:       Pat Thaler/Broadcom: This seems to be layering stuff on top of NVE that does not necessary belong there. Having access rules of who can talk to who to the NVE does not seem to be practically usable. We did considerable work at IEEE 802 for port extender and that did not get used. If you have packet that does not need to get into the tunnel because both endpoints are on the same side, just forward directly.  Lucy: Do you recommend to exclude the fourth solution?  Pat: I am saying that we support the upper two.  Lucy: Justification is exactly for these policy things.  Pat: I do not think for VMs that are in the same network that is applicable to be done here. Intra-VN traffic control should not be done here,  Pat: the top two cases, the traditional forwarding use cases - that I see being applicable. The third one - we already have that defined in IEEE 802. That is not an NVO3 thing - it is a question whether you go into the tunnel or not. If you want that kind of control then do not build such a setup, do not put bridge in the middle. Based on our IEEE 802 experience it did not get picked up in the industry. I do not thin it is NVO3's bus iness.  Benson/individual: I see use cases for these different topologies. I think it is simpler if we keep VN construct equivalent to VLAN construct.  Pat: yes.  Lucy: Can we poll for consensus?  Benson: we need more mailing list discussion on this,  8. Tom Herbert - Update on GUE and ILA 
 - (10 mins)
 Tom presenting.  - Update on GUE. - Have 7 header extensions. Not much changed in the last few months. - middle box identification of GUE packets - ICMP error handling - Stateful middle boxes - session identifier to identify the flow. Identifier Locator Addressing: - split ipv6 address to locator and identifier. - Applied NVo3 arch - Proceeding with Canary testing - Design of address system - Implementation of ILA testing Q&A:  David Black: How many times have we invented identifier/locator separation mechanisms in IETF?  Tom: how many encapsulations are there? I think by that number we win.  David Black: ICMP issues turn to be generic to tunnels, UDP tunnels in particular. Anything that is about tunnels goes to the intarea tunnels draft. UDP guidelines draft in tsvwg has jus finished LC. Can you please look at that draft, check whether there is everything what you need, and if there is something missing, let us know within two months.  Tom: there are different error handling modes used.  David: UDP encapsulation is a swiss army knife. If you using UDP and if there is any guideline that you do not want to follow, just let us know.  Jesse Gross: what about the number of extensibility mechanisms - there is a risk of partial implementations if they start to be stacked up.  Tom: yes, there are multiple types of extensions, they serve different purposes. There are concerns with TLV performance in hardware. We had many proposals to extend VXLAN, and every time it was noted that we need to maintain backward compatibility. We need to design a protocol that is both extensible and usable. If you do not exercise those extensions, few years later you may find that hardware either does not support those extensions, or performance is poor. On paper it may be designed to be very extensible, but in reality we may not be able to use it. This is the rationale for having more tnao one way for extensibility.  Jesse: my concern is that you have many choices, and possible permutations.  Benson: this is a good discussion.  9. Naoki Matsuhira - IPv6 address mapping encapsulation 
- (10 mins) Naoki presenting.  Tom Herbert: Do you have an equivalent for identifier/locator? Naoki: yes.  Tom: Did you look at the ethernet equivalent of it [???] Naoki: ..... Tom: We already have IPv4 address encoding, and IPv6 address encoding, but the problem with ethernet address encoding is that it is 48 bits, and that leaves 16 bits for VN identifier only.  Tom: This assumes that the prefix is less than 64 bits? Do you assume that the prefix is what routes packets in the network, and not the destination address?  Naoki: .... ----- Benson: this was the last presentation. End of meeting.