NVO3 WG Agenda, Vancouver, Monday November 4th, 09:00-11:30
=======================================================

Chairs: Benson Schliesser and Matthew Bocci
Note taker : Sam Aldrin and Linda Dunbar
Location and Date: Regency C room, 4th November 2013


Welcome (15 min) Ð Benson and Matthew

Meeting Administrivia (chairs, 15 min (notes, blue sheets, agenda bash, charter status, work plan)

- Note well, Blue sheets, Note takers + Jabber Ð All in place
- Few items in the agenda were moved to the last due to late arrival of slides
- Please send slides 1 day prior to the mtg, going fwd
- Some drafts being presented today, cannot be adopted as WG doc
- No RFCÕs. One doc is in Editors Q
- Many documents status is Ôon goingÕ. New revisions were published. Please review
- Loa: There is an idea for a non-WG BOF planned for London i.e. ÒScaling VPNÕsÓ. This will be talked in the RTG area open mtg


WG Document Updates (35 min)

Data Plane Requirements (Marc Lasserre, 5 min) 
draft-ietf-nvo3-dataplane-requirements-01
- No slides on this doc
- Editorial comments were sent. Some of them are consistent to help to write GAP analysis docs.
- Will be working this week to make those changes.
- Target is end of the week for final REV.


Security Requirements for NVO3 (Dacheng, 10 min)
draft-ietf-nvo3-security-requirements-01

- Introduce the latest progress in security req
- Last mtg, we got lot of comments. 
- Extract requirement sfrom the discussion and the list them in bullets. Every requirement is associated with justification and candidate techniques. 
- Imp one is to extract imp ones from discussion and list as bullets
- Revise assumption of analysis
- Deleted some content which is not relevant
- Prev version provided some security issues due to new features. This section is not really related, so removed.
- Assumptions of current work
- A. Underlying network, B. Network connecting NVEÕs/hypervisors, Malicious tenant systems. Compromised multi-tenant systems, etc
- Basic principle is to tolerate attacks from outside and confine inside attacks.
- In discussions, techniques considered were authentication, authorization, Packet level security, Key management etc
- Future, update the introduction to NVO3 arch
- Key mgmt. requirements should be carefully revised
- Discuss the influences to security requirements due to various NVo3 arch

- Two open qÕs to WG
A. NVE to NVE control traffic to be considered
B. When whole system is compromised, how to deal with it?

QÕs: 
Zhou : Have seen improvement in the doc but we cannot generally talk about security. We need to make clear which node etc needs to have authentication etc.
2. Key mgmt: We shouldnÕt allow this.

Larry: Arch allows security of NVA to NVA. NVE to NVe is less secure

Sam H. : One of the things to consider, whether key mgmt. is mandatory. In IETF, we signed up to work in broader context. Urge you take a look at that consensus stmt

Melinda : This falls outside the scope of the document. As this is requirement document, I am not sure this is appropriate for this doc.

Thomas: This should be closely aligned to arch doc. Two specific things, 
1. Inside and outside attacks, what does tenant sys do? What is missing is, someone who has access to underlay but not part of tenant sys. 
2. Sam H says it is good point.
3. Tenant sys generally do not know the virtualization going on.


Gap Analysis (Eric Gray, 20 min) 
draft-ietf-nvo3-gap-analysis-00
- WG was polled for adoption. Received good comments.
- Draft was adopted on 20th sept.
- Content comments were taken from requirement document.
- Decided not to adopt operational document. There are number of unresolved issues.
- Some wordings and content need to be corrected.
- Control plane requirements Ð lot of discussion on mailing list.
- Lot of discussion was more like arch rather than requirements
- Very little discussion on NVE-hypervisor document
- Mismatch between CP drafts and the areas for CP functionality
- Drafts are evolving. Because they are evolving, no fixed set of DP alternatives, it is difficult to have doc structure.
- Operational requirement was not adopted.
- No mgmt. requirements draft was on the horizon.
- At the time we wrote the doc, security requirements was not adopted. Should we take from security requirements doc or individual drafts, which address those security requirements?
- Does GAP analysis should deal with security requirements as a separate section?
- Structure is based mainly on DP requirements.
- Need to analysis on how each of the CP does this
- What areas/requirements actually need to be included in the GAP analysis?
- What needs to be in GA?
- Currently, Operational Req and Mgmt Req are TBD
- Next steps, respin the draft to address WG comments
- Update based on requirements update
- Need more input from WG.
- Last call after requirements are done

QÕs:
Lucy Yong: Two questions for chairs
* Many questions, but my question is, As there was lot of discussion, Is it right time to call for WG adoption? 
* Stewart: Bring the issue in RTG area open mtg. 
* Benson : I am happy with this. Reach out to me if y 
* Lucy: Should be one single doc or multiple docs to address all the GAP analysis?
* Matt: We said, there will be single doc with more detailed docs in separate docs.
* Lucy: Will those be made as RFC;s? 
* Matt: It is up to the WG.
* Benson: It is up to you (Lucy) to work with individuals to work on separate docs.
* Eric: Contribute text to the GA doc. 
* Yves: Clearly there is lot of confusion on how to interpret this draft. Solution put fwd based on CP and DP. Could not put this GA doc against the solution. So, written a new draft. Individual drafts are always necessary to support main doc.
* Nabil: I do concur with Matt said. Confirmed at ORL and Berlin to consider separate doc. It is up to WG to adopt or not.
* Eric: If we start on the belief, the problem is that, whose doc will be WG doc. Bad idea to open 
* Tina: This is the the better way to do the draft i.e. single draft.
* Yves: Current rev, doesnÕt support CP and DP solution.
* Thomas: TQ for trying and I feel for you. Solution docs were not written with GA in mind. Right approach is, contribute text to support a solution. Writing a new draft is not a right model.


Architecture Discussion (30min)


 
Architecture (Design Team, 20 min) 
draft-narten-nvo3-arch-01 
- Joint work with design team
- Major changes were, new section on dist gateways, replaced section about Push Vs Pull and improved text to better support adaptor offloads
- There is lot of confusion what is push and pull.
- NVE Ð NVA interactions are for Fault tolerance reasons
- What if NVA wants to partition, should NVE use multiple addresses? Recommendation; require NVE support multiple addresses per NVA
- Should NVE talk to NVE without NVA?
- If so, why do you have NVA and is there a need for that?
- NVE can still provide hints related to forwarding.
- If you want NVEÕs talk directly, Multicast is tricky
- Arch is much clear if NVE rely on NVA for info
- DP encap, No need for a new encap for NVo3
- Good to have a home for VXLAN and NVGRE
- CP should support multiple encaps.
- Support Gateways to perform translate one encap type to another.
- Next steps: WG need to adopt and what the arch should be. 
- Pretty hard to specify requirements if arch is not solidified.
- Request formal adoption

QÕs:
- Eric: Strongly support WG adoption
- Eric: Arch supports GWÕs, are you mandating GWÕs?
- Thomas: Not mandating any?
- Eric: What implementations should allow to do, rather than Push and pull. Those have implications on arch.
- Thomas: We did talked a lot about this. 
- Eric: Let us not make any assumption considering these to mandate any particular model.
- Lucy: Glad that dist GW into the doc. This also impacts other documents. We should also update to the FW doc.
- As the FW doc is in IEST review, where these should be documented.
- Benson: Arch document is the place. 
- Lucy: These changes in arch also have impact on FW doc.
- Benson: Let us take it offline to understand the Q better. If FW should be modified, we should do that, but I do not see that at this point.
- Marc: There is no need unless the the doc
- Linda : Dist GW is for overlay or for undelay? Is it for tenant systems?
- Thomas : for tenant systems.
- Linda: Is it for all VNÕs or subsets?
- Thomas: Could be subset
- Linda: Description is not clear on this.


   
NVE<->NVA communication for TRILL/LISPv(Linda Dunbar, 10 min)
draft-dunbar-nvo3-nva-gap-analysis-01
- TRILL and LISP are both overlay.
- Take what is good in LISP and use it for TRILL.
- Made a conscious decision to choose the things from LISP.
- In TRILL we took the information from pull based.
- In TRILL multiple directories could be configured. Choice is on NVE.
- When the info is not available, Lisp does native fwding or drop. TRILL is the same but inverse.
- TRILL has extra caching timer
- Lots of components are already present. Depending on the need one could take subset of LISP or TRILL


Next Steps (20 min)
Next Steps Discussion (Chairs, 20 min)
- We do not need a new data plane
- Process to re-chartering for  solutions
- Looking for consensus for existing DP solutions
- Looking for CP to support for various architectures.
- Will be polling WG, and chairs will document consensus in an individual draft. Anyt extensions will be evidnet form gap analysis.
- Lucy: What is the definition of ÔnewÕ DP?
- Matt: All existing DPÕs are not new DÕs
- Yves: Extensions to DPÕs new DP?
- Benson: Fair Q. Not out of scope. Will be considered as part of re-charter
- Thomas M : Documenting what is deployed about VXLAN and NVGRE
- Matt: I was asked to shepherd VXLAN doc. Will be outside of NVo3
- Benson: No one has requested publication of NVGRE, yet. For VXLAN, we were requested.
- Stewart: Where are we on this, in terms of process?
- Matt and Benson : No one has approached us. 
- Stewart : That is a bit of a problem.
- Yves: Currently GA doc is not ready. How you plan to deal this?
- Benson : this is up for discussion and no decision is made. 


Other GA/Applicability Statements (50 min)
*** These drafts will be presented to help the Gap Analysis or other WG drafts. 
*** None can be adopted currently. Speakers should focus on impact on WG drafts.



VXLAN L3VPN Encap (Lucy Yong, 15 min)
draft-yong-l3vpn-nvgre-vxlan-encap-03.txt
- This draft proposes a solution
- We use the NVGRE protocol type to indicate the payload
- No change in using other fields
- Request the use of reserved bit to indicate protocol type field
- Other things in the draft talks about the backward compatibility.
- As there is other proposals regarding VXLAN enhancement, we are trying to incorporate 

QÕs:
Eric O: If you want to use the field for protocol field, why donÕt you write a separate draft describing the prorocol field.
Lucy: Good comment.
Marc: If we consider vxlan and nvgre drafts in this WG, why donÕt you ask to incorporate in those instead of new docÕs
Benson: We will see when things get clarified

   
GRE in UDP
draft-yong-tsvwg-gre-in-udp-encap-02.txt
- GRE key field is used for LB function.
- Goal for this draft is to find a easier way to take advantage of this ECMP capability.
- Provide generic entropy field to support diff environments
- Works in majority of network environments
- Adds 16bit entropy field.
- Very minimal overhead and no need to go for UDP port
- Do we need two network virtualization overlay data encap methods
- i.e. diff udp port number
- Should IETF standardize one or both?

QÕs:
- Google: If you put UDP, why are you adding GRE?
- Anton: If you change UDP port, no application will process as this is not real UDP.

      
Generic Protocol Extensions in VXLAN (Paul Quinn, 5 min) 
draft-quinn-vxlan-gpe-01.txt
- Why VXLAN GPE?
- We define new flag field to indicate the protocol type present in the packet.
- Similar draft will be present in LISP.
- Working with Lucy to align on common format.


DHCP and Multicast Addresses in VXLAN (B. Sarikaya, 5 min)
draft-sarikaya-dhc-vxlan-multicast-02.txt
- multitenancy requires independent address space
- Second point is, RP address should be known.
- With Multicast, VTEP should know IP multicast address for VNI should be known
- Three types of solutions are given
- Please take a look and comment

QÕs
Dino Ð Are you going to use this mechanism to map inner multicast to outer multicast address?
Bechet Ð No.


L2TP Virtualization Profile. (Frank Xialiang 5 min)
draft-fan-l2tp-vp-00.txt
- Enhanced solution to support DP solution with L2TP VP.
- Simple ip based multi tenancy
- Focus on change to network side and transparency on client side
-  Support multiple services which is already supported with version 3 of L2TP
- Meet CP, DP, Security and be backward compatible
- Comments and suggestions are welcome. 


LISP Control Plane (Yves Hertogs, 10 min)
draft-hertoghs-nvo3-lisp-controlplane-unified-00.txt
- Wanted to have a separate draft about lisp, instead of being part of GA draft.
- Complimentary to draft-maino-nvo3-lisp-cp
- This draft should be used as input into GA draft.
- NVE supports ip and non-ip traffic, independent of subnets and VN locations

QÕs:
Lucy: Unified L2/L3, if non-ip, fwd as L2, for IP, use L3. But there are many cases where ip traffic is sent over L2 network. 
Yves: Agree and we could enhance for the same.


ForCES as NVE to NVA Control Protocol. (Jamal Hadi Salim, 10 min)
- Forces has control and data path separation.
- Forces provides a data model which is based on XML
- Meeting the nvo3 requirements with less complexity, and better HA
- Data model can model variety of mapping tables etc
- Provides model for event notifications
- Demo at Bits and bytes and also to the WG mtg

QÕs: 
Lucy: is it bidirectional?
Jamal: Yes.