IETF 87 NVO3 Meeting minutes: Location: Potsdam-3, InterContinental Hotel, Berlin, DE Time: 1-Aug-2013, 0900-1130 – Thursday, Morning Sessions I + II Chairs: Benson Schliesser (bensons@queuefull.net) & Matthew Bocci (matthew.bocci@alcatel-lucent.com) Note-taker: Sam Aldrin Scribe: TBD Jabber MUC: nvo3@jabber.ietf.org Web URL: http://tools.ietf.org/wg/nvo3/ Minutes: Welcome (15 min) A. Meeting Administrivia (chairs, 15 min)
(notes, blue sheets, agenda bash, charter status, work plan) - New ‘Note well’ - Milestone updates. Dates are all off, so, will be cleaning up. - Problem statement – IESG approved. - Framework – Last call completed. Please read the new version and comment on the mailing list - Data plane requirements – Please speak up if there are any comments - Control plane requirements – New version updated and adopted as WG document. - Use cases document is on the agenda. Please read and comment - NVGRE and VXLAN technologies are being deployed but the drafts do not have a home. - Proposing to update the charter and adopt these as informational in NVO3 Stewart – Do we need to get these as RFC’s? Two potential ways to do this. - 1. Adopt them in WG - 2. AD sponsored and publish - Question is, should we adopt or make it as AD sponsored - Benson – Should NV03 adopt these documents? - Questions: Tomas – Discussed in L3vpn and L2VPN. Should consider those WG;s as well. Lou – If we adopt, should there be no review at all? If so, why bring it to WG? Benson – Yes, no review and the doc should be high quality. Lou – Take protocol as is but take document process? Benson – Yes Stewart – Send it to IESG (?) Thomas M. – What is proposed in L2 and L3VPN is to re-use encaps. Stewart – Split control and data plane parts Benson – we haven’t said that (?) – Did you change the charter? Erik – Publish sooner? It depends on how long it takes to clean up and make changes to charter Benson – Yes Erik – What is written and deployed could be different Thomas N. – Industry needs a stable reference at this point. Need to know what authors are willing to do. i.e. to clarify. Benson – We are not making a decision now. Will take it up on mailing list. Upto IEST and Stewart. Thomas N – It is upto us to decide. Lucy – If we update the charter, please include the use case in the charter. Benson – There is a grey area. Want to be little cautious in making hcanges to charter. Stewart – A tiny well agreed update to charter is minimal. Significant change to charter will take time. Lucy – Use case is already WG doc, so, should change the charter now to include. Larry – speaking as co-author of VXLAN draft. Need to publish sooner or later with what we have. Benson – should we adopt these docs in NVo3 as is? Thomas M – You mean IETF? Thomas N – IETF ? Benson – Should we adopt as IETF? WG - Thomas M – Should it be, both encapsulations and control plane stuff or just encap? Benson – Should NVo3 adopt these docs? Lucy – Question should provide option if not NVo3, where> Stewart – If I am asked to shepherd as AD, I would do it. Else, if Nvo3, then Benson – Should Stewart be doing or NVo3? Thomas – WG cannot take these doc and own, rather should publish the doc Navin – If we do not adopt and review may not be right way, in order to publish Lucy – either way will go with same IPR process Stewart – these docs are just informational WG Document Updates (20 min) B. Framework (Marc Lasserre, 10 min) 
draft-ietf-nvo3-framework - Few changes made based on comments received on the list - NVA is now added to reference model - Few minor editorial changes. Clarified some of the terms. - Clarified the terms encapsulation/tunneling - Ready for LC Questions: - Benson – Any comments? None received. C. Use Cases (Lucy Yong, 10 min) 
draft-ietf-nvo3-use-case - We made several changes since last IETF Udates to the draft - Added VN to carry multicast traffic - Added VN zoning allowing to play with policy and zones - DC provider host web applications - Added Vinay and Ramki as contributors - Editorial work Details: - Zoning of VNs - DMZ provides services to zones - Comments or suggestions? Ready for LC Questions: Matt – Any coments? Who all read this draft? Would request WG to read and provide comments Requirements & Gap Analysis (45 min) D. Data Plane Requirements (Marc Lasserre, 10 min) 
draft-ietf-nvo3-dataplane-requirements - DP requirements hasn’t changed since last time - Minor editorial and ready for LC Questions: Matt: Who read this draft? Few!! Pat – Would be nice when mentioning what draft is being asked instead of just putting ‘00’ version. E. Operational Requirements (Peter, 10 min) 
draft-ashwood-nvo3-operational-requirement - When presented first, I said ‘ll steal from RFC6136. Thanks Ali. - 26 requirements are identified - We got additional 8 requirements - Went through all the documents to see if all of them are covered or not - Mapped the NV03 requirements and mapped to requirements - We need more feedback, especially on MUST and MAY - We need to clean up the document and prune the requirements Questions: David – regd L2 and L3VPN, should someone from L2 and L3 go through the requirements? Thomas M – L3VPN has no OAM requirements Peter – If any volunteers please contact. Benson – how many read the doc? Few Thomas N – No brainer for doc to be adopted as WG doc. Would like to know what are the steps to adoption Benson – Will poll for adoption. Stewart – A WG adoption is an adoption and not perfection. Chairs could do on their own authority. Benson – we are biased to adopt. So that makes life easy. F. Security Requirements (Dacheng Zhang, 10 min) 
draft-hartman-nvo3-security-requirements - We have presented in the last IETF mtg - Add a section to introduce NV03 overlay - New attacker category - Introduced automatic key management mechanisms - Added analysis of attacks on data plane - Introduced new category ‘ threat model’ - Inside attacks and outside attacks depending on the privilege category. - As outside attack – it is possible to intercept packets and spoof the network. It is possible to disrupt the network connectivity - Insider attack could do like outside but has privileges to the network. Impersonate others using the credential information - In security properties – Isolation of networks, spoofing detection, Integrity and availability of control plane. - Confidentiality and integrity of the data traffic and also the control plane. - In the last version, we didn’t discuss the responsibility of NVo3 to securely transport over overlay network. Questions: Benson – Thank you for doing this. There fairly profound impacts on the requirements. So, please do read the draft and bring questions. Benson – do we want single doc or multiple ones for CP, CP etc. David B – there should be one single security doc to have one big picture. On this draft, I do like what I see in here. One minor comments is regd outsider attack like eaves dropping, modification etc. Margaret W – Interest in the draft. Every doc should have security section. There should be security requirement document and each solution could specify how to achieve those. Benson – I personally like that approach. Margaret – If we think upfront, it will be easier to do stuff than encountering the issues later. Benson – who all read this draft? Few G. Gap Analysis (Nabil Bitar, 15 min) 
draft-gbclt-nvo3-gap-analysis Architecture (45 min) - This is the merge of 3 different drafts - Two additional drafts exist, one is related to TRILL. Another one is related to IP, IPVPN, etc. There not much we could adopt from this. Would like to talk to authors. - Started with the cheng draft. Added cp requirements, analysis tables and manageability information. Issues: - Continually monitor and keep upto date with requirements - Sometimes yes/no is useful but not all the time. - Would like to hear if there are any missing technologies other that already identified. Next steps: - Not ready for WG adoption. - Need to add keep pace with requirements and modify accordingly Questions: J – There are five technologies. Two of them are just DP technologies. Could you separate them from others? Nabil – Why we have like these is because these are de-facto standards. For ex: There is some CP elements in VXLAN, but point well taken. Ali – VPLS should be in different category from to others. Nice to have summary table as well. Nabil – there is other doc. Talking about it. This is light weight document. Benson – Better not go deeper into the analysis, IMO. Need to find balance. Thomas M – Having multiple drafts may make it easy for other WG’s to review. Better for each technology to have separate doc, if not , separate technology section? Thomas N – What is the purpose of the GAP analysis? IT needs to further the goals and the doc should documented accordingly. We should go ahead and adopt it right away, so that we could have a single document. Nabil – I didn’t feel like asking a 00 version draft. Upto the WG doc. Lucy – Technology specific drafts? Benson – Fair question and will be lot of overlap. No answer for now. Florin – Definitely move towards adoption. If we delay, solution will get developed elsewhere. Marc – More useful to have requirements listed per technology. Benson – Would like to collaborate with WG’s Thomas M. – Gap analysis on different techniques? Marc L – If we already picked set of solutions, we should stop there. H. Architecture (Design Team, 45 min) 
draft-narten-nvo3-arch Presentation: - Purpose is to identify the arch components - Key is for multiple components to work with each other. - Arch decisions we make leads to requirements and feed into GAP analysis. - Need to have NVA protocol for NVA’s to talk to each other. - Lot of encap discussion and WG should NOT bless one over the other - Arch should support multiple encaps Questons: Anoop – Does that mean there is encap translation? Dave M – Can have any number of encaps, will it scale? David B – Translations out to be workable. Thomas M – Should rule out GW from translation. Should advt? Thomas N – Using negotiation loosely. Some sort of communication for encap types Luyuan – I was referring to inter data centers, not intra-DC. Marc – If translation has impact DP requirements, we do not want to deal with translation, except identified like VNID etc. Joe Plessier – We are not going to specify the encap, how do we specify the translation? Thomas N – Technologies are close enough and the attributes are common. We should not be tackling any to any? Joe – will thee be a doc specifying small number to number of encaps? Thomas N – We will not pick one doesn’t mean we will not talk about encaps. Presentation: (contd) - Goal is NVE should implement NVO3 functionality once. - Future innovation will be within NVA’s Questions: Luyuan – cannot say NVE is stable and only NVA requires it. Thomas N. – If both NVE and NVA keep changing, it cannot be done Luyuan - should be minimal. Nabil – intention is not to change NVo3 functionality, not NVE. Joe – It doesn’t mean upgrading NVA will break NVE. Samita – Are we considering hierarchical model or just p2p communication? Thomas N. That is long way to discuss Thomas M.- the NVA protocol could be proprietary? Thomas N. – Look at the requirements and the protocol model then make a choice. Ali – Is it one protocol for NVE to NVA? Also, should be done here or elsewhere. Nabil – The requirements should drive the goal Presentation : contd Internal NVA Org - Reliability requirements implies distributed technologies and using cluster tech David – BGP work cannot be done here. Just take the requirements to the respective group. NVA Federations: - NVA domain – admin construct; NVA, NVE, VN’s etv - NV region – two or more NV domains - NVA’s will share info with each other based on operator policy and network basis - Clean interface between NVA’s Questions : Lucy – Is there a reason why communication between Hypervisor and NVA is excluded? Thomas N. – IT is in doc but not talked ? – have you looked at where, IAAS is used and not owned. David – Not yet. ? – Look at the actual requirements and see ETSI/NFV is doing. Lucy – Read UC draft, which describes it. Presentation : contd Push Vs Pull: - Much discussion whether one is better over other. - Arch should support both and cannot rule one over the other Questions : Thomas M. – We might be building a big steam engine. What would be the most interesting balance between too. Thomas N. – Cannot rule one over the other Thomas M – Already solutions are describing one is better over other. Linda – We do both push and pull in TRILL. Even though we do not prescribe, need to describe Dino - LISP has both push and pull. David – Last time we put an abstract slide regd push vs pull. Questions: Florin – Should we discuss again as we discussed in FW? Thomas N. – We had strong discussion on push vs pull. Should put requirements. Naveen – Are we precluding NVA is present always between NVE’s? Thomas – No. New Draft Introductions (Time Permitting) I. TRILL Directory NVA Gap Analysis (Linda Dunbar, 10 min) 
draft-dunbar-nvo3-nva-gap-analysis - NO TIME for this preso Questions: J. NaaS Requirement in CDC (Peng Fan, 10 min) 
draft-li-nvo3-clouddatacenter-requirement - NO TIME for this preso Questions: