Re: [nvo3] [ALU] Roundtable sessions in Seoul

"Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com> Tue, 15 November 2016 09:15 UTC

Return-Path: <matthew.bocci@nokia.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FB0129A5A for <nvo3@ietfa.amsl.com>; Tue, 15 Nov 2016 01:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.401
X-Spam-Level:
X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iihrXR18FefL for <nvo3@ietfa.amsl.com>; Tue, 15 Nov 2016 01:15:31 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46414129537 for <nvo3@ietf.org>; Tue, 15 Nov 2016 01:15:31 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 86C7193667D23 for <nvo3@ietf.org>; Tue, 15 Nov 2016 09:15:24 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAF9FPTC002111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nvo3@ietf.org>; Tue, 15 Nov 2016 09:15:26 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uAF9FORO017845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <nvo3@ietf.org>; Tue, 15 Nov 2016 10:15:25 +0100
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Tue, 15 Nov 2016 10:15:25 +0100
From: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
To: NVO3 <nvo3@ietf.org>
Thread-Topic: [ALU] [nvo3] Roundtable sessions in Seoul
Thread-Index: AQHSPyDLM2UjJUfdOkSjD3rTCjkcZQ==
Date: Tue, 15 Nov 2016 09:15:24 +0000
Message-ID: <C6CA2425-80F3-45C5-93D3-A79399170CA8@nokia.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_C6CA242580F345C593D3A79399170CA8nokiacom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/l9XRdbH-7AT2yr4v1an_UkNE2rc>
Subject: Re: [nvo3] [ALU] Roundtable sessions in Seoul
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2016 09:15:34 -0000

WG

We have now narrowed these down to the following three topics for discussion. Please have a think about these questions and contribute to the sessions tomorrow.

Many thanks to Greg, Benson and Pat for offering to chair the roundtable discussions.

Matthew




  1.  OAM
–      What is really important for encapsulation design team? Specific requirements on encapsulation and control plane. What OAM visibility is required E2E in NVO3 architecture?


  1.  Control Plane
–      What standardisation work do we need for NVE-NVA control plane and management plane? What are the protocol options? What is needed from YANG models vs. dynamic control protocols ?


  1.  Data Plane
–      Extension options for NVO3 encapsulation. What is really needed?






From: Dacheng Zhang <nvo3-bounces@ietf.org> on behalf of "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
Date: Saturday, 12 November 2016 at 03:28
To: NVO3 <nvo3@ietf.org>
Subject: [ALU] [nvo3] Roundtable sessions in Seoul

WG,

As discussed during our recent virtual interim meeting, we would like to try an experiment in Seoul in the form of roundtable sessions focussed on a number of topics of importance to NVO3. The objective is not just to stimulate discussion in these areas, but to identify key issues that can be used as input to our existing milestones e.g. promote more critical review of existing drafts and help with the development of new ones.

We will hold the round tables during the second half of the first NVO3 meeting on Wednesday.

We would greatly appreciate volunteers to help lead each of these and report back on their discussions during the second NVO3 session on Thursday.

Please find a list of potential topics below.

We would like to narrow this down to 4 or 5 topics closer to the meeting.

Please post any comments on this to the NVO3 mailing list.

Best regards

Matthew and Sam



1)  Please walk through how a program in an NVO3 data-center sending a traceroute (ICMP-based, UDP-based, etc.) works.  Consider intra-data-center cases, inter-data-center cases, cases where the sender is a process in a VM, and cases where the sender is on a bare-metal machine.  What assumptions about encapsulating header-size need to be made?  What changes for ping and MTU discovery?  Please write down needed functionality at each point in the network.  Add pointers to relevant drafts as appropriate.



2)  What parts of the network need to be able to parse an NVO3 packet?  What parts need to modify the NVO3 header?  When should a transit router (and other devices) drop an NVO3-encapsulated packet if it can't understand an included option?  Consider ECMP/load-sharing issues.  Consider packets sent to/from a process in a VM, on a bare-metal machine, intra-data-center, and inter-data-center cases.  Please write down needed functionality and reasons at each point.  Add pointers to relevant drafts as appropriate.



3) An option for data-centers today is to use EVPN with VXLAN-encapsulated packets; even though the VXLAN included Ethernet frames, that can be added/removed at the edges using EVPN.  What improvements to this should NVO3 be focused on?  Is there already work going on to be sped up?  Where is more work needed?  What problems do you see for inter-data-center, intra-data-center, and bare-metal machine interworking?

5) Please come up with a categorization for extensions/options that are needed in NVO3 encapsulation.  What is the trade-off between interoperability and vendor independence?  What different behaviors need to be expressed for proper functioning for each different device in the network - considering inter-data-center, bare-metal machines with gateways, as well as intra-data-center, and VMs with hypervisors, etc.

6) EVPN is a distributed control-plane approach for NVO3.   Is a more orchestrated approach needed?  What are the important features for this?  What are the OAM implications? What are existing control-plane implementations (standardized or non-standardized) that should be considered and why?  Please include pointers to existing work.  Please include technical perspectives on the advantages and disadvantages.


7) Different aspects of security and privacy need to be considered to data-centers depending on the use-cases.  A data-center that serves only internal enterprise customers may have very different requirements from a data-center that supports multiple external customers or passes around privacy-sensitive information.  What are the options and points to look at describing potential functionality desired?   For instance, a process may use IPSec to protect its packets.  A hypervisor might encapsulate in NVO3 but can IPSec be used between hypervisors or does the transit network need to see the NVO3 encapsulation data?   How can or should NVO3 encapsulation options/extensions be protected?  Is that integrity, confidentiality, or more?  What are the guidelines to set for NVO3 options/extensions?  What are the considerations and differences when multicast is brought into the discussion?  Please write down a suggested architecture with functionality clearly defined at different parts of the network.  References to existing work are strongly encouraged.  Please consider all dimensions of deployment - VM processes, bare-metal machines, intra-data-center and inter-data-center, etc.