From nobody Tue Jul 1 00:24:51 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FE41A0185 for ; Tue, 1 Jul 2014 00:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.071 X-Spam-Level: * X-Spam-Status: No, score=1.071 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 b_IoPkpBXzJk for ; Tue, 1 Jul 2014 00:24:47 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id B682F1A017D for ; Tue, 1 Jul 2014 00:24:46 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app11-12011 (RichMail) with SMTP id 2eeb53b26237207-4a207; Tue, 01 Jul 2014 15:24:39 +0800 (CST) X-RM-TRANSID: 2eeb53b26237207-4a207 Received: from vicwork (unknown[183.244.51.220]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee353b26237f33-32bae; Tue, 01 Jul 2014 15:24:39 +0800 (CST) X-RM-TRANSID: 2ee353b26237f33-32bae From: "Vic Liu" To: "'Sam Aldrin'" , Date: Tue, 1 Jul 2014 15:24:55 +0800 Message-ID: <008201cf94fd$8eee6aa0$accb3fe0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01CF9540.9D126DF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+U/Wgk9vv1HIgVTdedtObg+/yxUg== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/rtW_oGKiqLT6Q-T3YD6F2O3cSRA Subject: [nvo3] IETF 90 NVo3 Slot Requests - Toronto X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 07:24:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0083_01CF9540.9D126DF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sam, We need a slot to present " draft-liu-NVo3-PS-VxLAN-perfomance-00.txt". - topic: Problem Statement for VxLAN Performance Test - draft: draft-liu-NVo3-PS-VxLAN-perfomance-00.txt - brief statement of objectives and issues that need to be discussed and resolved via the presentation during the meeting : problem statement for VxLAN performance and test methodology on VSwitch - requested duration (norm is 10 min): 5 minutes - speaker Given-name FAMILY-NAME: Vic Liu -draft will be post to mail list soon. Thanks Vic Liu China Mobile ------=_NextPart_000_0083_01CF9540.9D126DF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Sam,=

We need a slot = to present " = draft-liu-NVo3-PS-VxLAN-perfomance-00.txt".

=  
- = topic: Problem Statement for VxLAN Performance = Test

- draft: = draft-liu-NVo3-PS-VxLAN-perfomance-00.txt

- = brief statement of objectives and issues that need to be discussed and = resolved via the presentation during the meeting : problem statement for = VxLAN performance and test methodology on VSwitch   =

- requested = duration (norm is 10 min):  5 minutes

- = speaker Given-name FAMILY-NAME:  Vic = Liu

-draft will be = post to mail list soon.

 

Thanks
Vic = Liu

China = Mobile

 

------=_NextPart_000_0083_01CF9540.9D126DF0-- From nobody Tue Jul 1 02:13:33 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9FB1B27EA; Tue, 1 Jul 2014 02:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 qqPim7SW6swE; Tue, 1 Jul 2014 02:13:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8931A0644; Tue, 1 Jul 2014 02:13:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701091324.13817.60936.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 02:13:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/nsDIewqNr5wwmtdialBgDsxc7Sg Cc: nvo3@ietf.org Subject: [nvo3] I-D Action: draft-ietf-nvo3-hpvr2nve-cp-req-00.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 09:13:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Virtualization Overlays Working Group of the IETF. Title : Hypervisor to NVE Control Plane Requirements Authors : Yizhou Li Lucy Yong Lawrence Kreeger Thomas Narten David Black Filename : draft-ietf-nvo3-hpvr2nve-cp-req-00.txt Pages : 20 Date : 2014-06-30 Abstract: This document describes the control plane protocol requirements when NVE is not co-located with the hypervisor on a server. A control plane protocol (or protocols) between a hypervisor and its associated external NVE(s) is used for the hypervisor to populate its virtual machines states to the NVE(s) for further handling. This document illustrates the functionalities required by such control plane signaling protocols and outlines the high level requirements to be fulfiled. Virtual machine states and state transitioning are summarized to help clarifying the needed requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nvo3-hpvr2nve-cp-req/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nvo3-hpvr2nve-cp-req-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 1 10:17:07 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9531B2863 for ; Tue, 1 Jul 2014 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 q67h-OZZUQf8 for ; Tue, 1 Jul 2014 10:17:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A261B288C for ; Tue, 1 Jul 2014 10:17:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJL75579; Tue, 01 Jul 2014 17:17:00 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Jul 2014 18:16:59 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Tue, 1 Jul 2014 10:16:55 -0700 From: Lucy yong To: Sam Aldrin , "nvo3@ietf.org" Thread-Topic: [nvo3] IETF 90 NVo3 Slot Requests - Toronto Thread-Index: AQHPkxwonTcJWt4rxEuDa8z903TATZuLeKSQ Date: Tue, 1 Jul 2014 17:16:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453B0B15@dfweml701-chm.china.huawei.com> References: <5CC4F625-4B2A-4B70-8D1D-52676222A7B5@gmail.com> In-Reply-To: <5CC4F625-4B2A-4B70-8D1D-52676222A7B5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.13] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453B0B15dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/5yR4Dz-RDBDdzrDTA72PREZtHrQ Subject: Re: [nvo3] IETF 90 NVo3 Slot Requests - Toronto X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 17:17:04 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453B0B15dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, - topic: network virtualization edge (NVE) data plane interoperability func= tionality - draft URL: http://datatracker.ietf.org/doc/draft-ietf-nvo3-nve - brief statement of objectives and issues that need to be discussed and re= solved via the presentation during the meeting: address for the interoperab= ility between an NVE and its attached tenant systems and between the NVEs - requested duration: 10 min - speaker name: Lucy Yong Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D453B0B15dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sam,

 

- topic: network virtualization edge (NVE) data plane interoperability fun= ctionality

- draft URL: &n= bsp;http://datatracker.ietf.org/doc/draft-ietf-nvo3-nve  

- brief statement of objectiv= es and issues that need to be discussed and resolved via the presentation d= uring the meeting: address for the interoperability between an NVE = and its attached tenant systems and between the NVEs

- requested duration: 10 min =  

- speaker name:  Lucy Yong

 

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D453B0B15dfweml701chmchi_-- From nobody Tue Jul 1 12:27:08 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A431B28D1; Tue, 1 Jul 2014 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 i7fWpgiPm2iO; Tue, 1 Jul 2014 12:27:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 651331A04B7; Tue, 1 Jul 2014 12:27:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701192705.15953.72380.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 12:27:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/Rndhj31Ag77aCNVwFERch4QNucs Cc: nvo3@ietf.org Subject: [nvo3] I-D Action: draft-ietf-nvo3-use-case-04.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 19:27:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Virtualization Overlays Working Group of the IETF. Title : Use Cases for DC Network Virtualization Overlays Authors : Lucy Yong Huawei Technologies, Mehmet Toy Aldrin Isaac Vishwas Manral Linda Dunbar Filename : draft-ietf-nvo3-use-case-04.txt Pages : 16 Date : 2014-07-01 Abstract: This document describes DC Network Virtualization (NVO3) use cases that may be potentially deployed in various data centers and apply to different applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nvo3-use-case/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nvo3-use-case-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-use-case-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 2 02:48:49 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651D01B2869; Wed, 2 Jul 2014 02:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 uxNoc90vybaI; Wed, 2 Jul 2014 02:48:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB6A1B28E5; Wed, 2 Jul 2014 02:48:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702094841.19406.56410.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 02:48:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/LTaegxUHpt5VaTng90lovuvt7JI Cc: nvo3@ietf.org Subject: [nvo3] I-D Action: draft-ietf-nvo3-framework-08.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 09:48:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Virtualization Overlays Working Group of the IETF. Title : Framework for DC Network Virtualization Authors : Marc Lasserre Florin Balus Thomas Morin Nabil Bitar Yakov Rekhter Filename : draft-ietf-nvo3-framework-08.txt Pages : 25 Date : 2014-07-02 Abstract: This document provides a framework for Data Center (DC) Network Virtualization Overlays (NVO3) and it defines a reference model along with logical components required to design a solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nvo3-framework-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-framework-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 06:32:36 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F052D1B29D5 for ; Thu, 3 Jul 2014 06:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 5F9jvU-3xVct for ; Thu, 3 Jul 2014 06:32:33 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with SMTP id 5433A1B29D6 for ; Thu, 3 Jul 2014 06:32:31 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee753b55b6cc5b-2dc5b; Thu, 03 Jul 2014 21:32:30 +0800 (CST) X-RM-TRANSID: 2ee753b55b6cc5b-2dc5b Received: from vicwork (unknown[114.246.227.152]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee353b55b6c4ae-71fc7; Thu, 03 Jul 2014 21:32:29 +0800 (CST) X-RM-TRANSID: 2ee353b55b6c4ae-71fc7 From: "Vic Liu" To: "'Sam Aldrin'" , Date: Thu, 3 Jul 2014 21:32:46 +0800 Message-ID: <005801cf96c3$46fc4240$d4f4c6c0$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+Wwyyo5Hta1hlLT5G9I2pZLJ3CUQ== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/zYpmUs48fwdbeqNWZDrpRbqAOSA Subject: [nvo3] request for time slot New Version Notification for draft-liu-nvo3-ps-vxlan-perfomance-00.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:32:35 -0000 Hi Sam, We've upload the draft " draft-liu-NVo3-PS-VxLAN-perfomance-00.txt". = Thank you! =20 - topic: Problem Statement for VxLAN Performance Test - draft: draft-liu-NVo3-PS-VxLAN-perfomance-00.txt - brief statement of objectives and issues that need to be discussed and = resolved via the presentation during the meeting : problem statement for = VxLAN performance and test methodology on VSwitch =20 - requested duration (norm is 10 min): 5 minutes - speaker Given-name FAMILY-NAME: Vic Liu -draft will be post to mail list soon. =20 Thanks Vic Liu China Mobile -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=883=E6=97=A5, = =E6=98=9F=E6=9C=9F=E5=9B=9B 21:23 =E6=94=B6=E4=BB=B6=E4=BA=BA: Vic Liu; Bob Mandeville; Zu Qiang; Weiguo = Hao; Zu Qiang; Bob Mandeville; Brooks Hickman; vic; Brooks Hickman; Hao = Weiguo =E4=B8=BB=E9=A2=98: New Version Notification for = draft-liu-nvo3-ps-vxlan-perfomance-00.txt A new version of I-D, draft-liu-nvo3-ps-vxlan-perfomance-00.txt has been successfully submitted by Vic Liu and posted to the IETF = repository. Name: draft-liu-nvo3-ps-vxlan-perfomance Revision: 00 Title: Problem Statement for VxLAN Performance Test Document date: 2014-07-03 Group: Individual Submission Pages: 12 URL: = http://www.ietf.org/internet-drafts/draft-liu-nvo3-ps-vxlan-perfomance-00= .txt Status: = https://datatracker.ietf.org/doc/draft-liu-nvo3-ps-vxlan-perfomance/ Htmlized: = http://tools.ietf.org/html/draft-liu-nvo3-ps-vxlan-perfomance-00 Abstract: As the number of data center tenant increased, 4K VLANs, mobility, broadcasting issues have become the network bottleneck. VxLAN has being take into consideration in China Mobile IDC. There are two implementation solutions for VXLAN. The first one is that NVE resides in TOR (top of rack switch), another one is that NVE resides in V-Switch established in hypervisor of physical server. For virtualized network, it's much better to implement NVE in V- switch because it's directly connect with Virtual Machines and easier for business to carry on. As we research in VxLAN solution, some problems are take into our considerations. How much resources will be consumed by VxLAN in a virtualized network environment. This draft introduces the problem for VxLAN performance by test. There is no methodology which can effectively evaluate VxLAN forwarding performance. This draft also attempts to address this issue, give a VXLAN performance evaluation method, especially when VxLAN resides in the virtual switch. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Thu Jul 3 06:40:25 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2567B1B29BA for ; Thu, 3 Jul 2014 06:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 vZzDw03Eqzjn for ; Thu, 3 Jul 2014 06:40:22 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with SMTP id F0E3B1A007F for ; Thu, 3 Jul 2014 06:40:21 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee653b55d4406a-7d06a; Thu, 03 Jul 2014 21:40:21 +0800 (CST) X-RM-TRANSID: 2ee653b55d4406a-7d06a Received: from vicwork (unknown[114.246.227.152]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea53b55d44f12-6c4c6; Thu, 03 Jul 2014 21:40:21 +0800 (CST) X-RM-TRANSID: 2eea53b55d44f12-6c4c6 From: "Vic Liu" To: "'Sam Aldrin'" , Date: Thu, 3 Jul 2014 21:40:37 +0800 Message-ID: <005901cf96c4$5fc64720$1f52d560$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+WxFfCH4SH6wT4T3+MgZ7jPcOLhg== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/PfoD5f0VJw3FaB_5nJH7qxNCoSA Subject: [nvo3] request for time slot: New Version Notification for draft-liu-nvo3-naas-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:40:24 -0000 Hi Sam, Please kindly give me a time slot for Network as a Service Architecture =20 - topic: Network as a Service Architecture - draft: draft-liu-nvo3-naas-arch-01 - brief statement of objectives and issues that need to be discussed and = resolved via the presentation during the meeting : introduction of = nerwork as a service architecture in IDC.=20 - requested duration (norm is 10 min): 5 minutes -URL: = http://www.ietf.org/internet-drafts/draft-liu-nvo3-naas-arch-01.txt - speaker Given-name FAMILY-NAME: Vic Liu/Liang Xia=20 =20 Thanks Vic Liu China Mobile -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=883=E6=97=A5, = =E6=98=9F=E6=9C=9F=E5=9B=9B 21:26 =E6=94=B6=E4=BB=B6=E4=BA=BA: Liang Xia; Liang Xia; Vic Liu; vic =E4=B8=BB=E9=A2=98: New Version Notification for = draft-liu-nvo3-naas-arch-01.txt A new version of I-D, draft-liu-nvo3-naas-arch-01.txt has been = successfully submitted by Vic Liu and posted to the IETF repository. Name: draft-liu-nvo3-naas-arch Revision: 01 Title: Network as a Service Architecture Document date: 2014-06-30 Group: Individual Submission Pages: 10 URL: = http://www.ietf.org/internet-drafts/draft-liu-nvo3-naas-arch-01.txt Status: = https://datatracker.ietf.org/doc/draft-liu-nvo3-naas-arch/ Htmlized: http://tools.ietf.org/html/draft-liu-nvo3-naas-arch-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-nvo3-naas-arch-01 Abstract: This draft provides an high-level overview architecture of Network as a Service (NaaS) system, and describes how every component of it works together from different aspects (i.e., data plane, control plane, management plane, etc) of NaaS system. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Thu Jul 3 06:50:34 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD071B29D7 for ; Thu, 3 Jul 2014 06:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 Vma49rhEsSpS for ; Thu, 3 Jul 2014 06:50:29 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with SMTP id 606C61B29E8 for ; Thu, 3 Jul 2014 06:50:28 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee753b55fa2edb-2dedb; Thu, 03 Jul 2014 21:50:27 +0800 (CST) X-RM-TRANSID: 2ee753b55fa2edb-2dedb Received: from vicwork (unknown[114.246.227.152]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee953b55fa3c31-829a5; Thu, 03 Jul 2014 21:50:27 +0800 (CST) X-RM-TRANSID: 2ee953b55fa3c31-829a5 From: "Vic Liu" To: Date: Thu, 3 Jul 2014 21:50:44 +0800 Message-ID: <000001cf96c5$c935e570$5ba1b050$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+WxZPVfFQO4SVlQYG86xgYbtBWFg== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/Ut-khTEvPQgRvSpLfPQn32eijGo Subject: [nvo3] request for comment : New Version Notification for draft-liu-nvo3-ps-vxlan-perfomance-00.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:50:31 -0000 Hi all We are doing an interesting work that we figure out a methodology to = evaluate the VxLAN performance on Virtual network. And find some issues = during testing. Please kindly review this draft. Any comment and discussion are welcome. Thank you=20 All the best! Vic -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=883=E6=97=A5, = =E6=98=9F=E6=9C=9F=E5=9B=9B 21:23 =E6=94=B6=E4=BB=B6=E4=BA=BA: Vic Liu; Bob Mandeville; Zu Qiang; Weiguo = Hao; Zu Qiang; Bob Mandeville; Brooks Hickman; vic; Brooks Hickman; Hao = Weiguo =E4=B8=BB=E9=A2=98: New Version Notification for = draft-liu-nvo3-ps-vxlan-perfomance-00.txt A new version of I-D, draft-liu-nvo3-ps-vxlan-perfomance-00.txt has been successfully submitted by Vic Liu and posted to the IETF = repository. Name: draft-liu-nvo3-ps-vxlan-perfomance Revision: 00 Title: Problem Statement for VxLAN Performance Test Document date: 2014-07-03 Group: Individual Submission Pages: 12 URL: = http://www.ietf.org/internet-drafts/draft-liu-nvo3-ps-vxlan-perfomance-00= .txt Status: = https://datatracker.ietf.org/doc/draft-liu-nvo3-ps-vxlan-perfomance/ Htmlized: = http://tools.ietf.org/html/draft-liu-nvo3-ps-vxlan-perfomance-00 Abstract: As the number of data center tenant increased, 4K VLANs, mobility, broadcasting issues have become the network bottleneck. VxLAN has being take into consideration in China Mobile IDC. There are two implementation solutions for VXLAN. The first one is that NVE resides in TOR (top of rack switch), another one is that NVE resides in V-Switch established in hypervisor of physical server. For virtualized network, it's much better to implement NVE in V- switch because it's directly connect with Virtual Machines and easier for business to carry on. As we research in VxLAN solution, some problems are take into our considerations. How much resources will be consumed by VxLAN in a virtualized network environment. This draft introduces the problem for VxLAN performance by test. There is no methodology which can effectively evaluate VxLAN forwarding performance. This draft also attempts to address this issue, give a VXLAN performance evaluation method, especially when VxLAN resides in the virtual switch. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Thu Jul 3 13:42:18 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C761B29DD for ; Thu, 3 Jul 2014 13:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 fKSPhPzxgf1s for ; Thu, 3 Jul 2014 13:42:13 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC62C1B2B5A for ; Thu, 3 Jul 2014 13:42:13 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so747206qcw.17 for ; Thu, 03 Jul 2014 13:42:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ETvo5XoHOl5DnEszVM83ZedosDTJuDNg+CW5xFyodEo=; b=m+5dldeHJwks31gwJAFN/D0brI7FnZBf+uA4GwNw2p+w6I5xQ3Nj+SDELZKHIbnrMB Ieak+OeAhbSJDPOnWlPEnAzGoF9h3wrA6U7PAaDB6rkyumBx8xI6W7NADmZiKk5vEmlw pGnwTyu+Z3zFjF6FuhXIhsTol319hXxnfTDHsDEZThd4NmpRXwe1tG0piaeKTH0Fw0OO tB9bRcn0i6/bZbkwkio6a5IJSCqZffsfNcOg4I0BiLq5VTSMAp+7js99GvHzXw5/D1r7 dwxsfCRKQlHVadXNiOybmOO4J1DgEZjArJFqWf4jThrXrlYb8VWIv0+56148nJPPznd0 lLOg== X-Gm-Message-State: ALoCoQmQmvrAG0e9+6I6jxIIGlFjLNY2pJoXzQSxjlvpZVwAz7hykGy5cmreeHv9QUo3NP45s8qa MIME-Version: 1.0 X-Received: by 10.224.156.132 with SMTP id x4mr11313508qaw.101.1404420132883; Thu, 03 Jul 2014 13:42:12 -0700 (PDT) Received: by 10.140.42.203 with HTTP; Thu, 3 Jul 2014 13:42:12 -0700 (PDT) Received: by 10.140.42.203 with HTTP; Thu, 3 Jul 2014 13:42:12 -0700 (PDT) In-Reply-To: <20140703203944.25295.49227.idtracker@ietfa.amsl.com> References: <20140703203944.25295.49227.idtracker@ietfa.amsl.com> Date: Thu, 3 Jul 2014 16:42:12 -0400 Message-ID: From: Benson Schliesser To: nvo3@ietf.org Content-Type: multipart/alternative; boundary=089e0139fe0e22e4fd04fd500bb8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/x0xBRMX2s9nUIjxUutU0maF7Jrw Subject: [nvo3] Fwd: xml2rfc v2 transition X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:42:15 -0000 --089e0139fe0e22e4fd04fd500bb8 Content-Type: text/plain; charset=UTF-8 ---------- Forwarded message ---------- From: "RFC Series Editor" Date: Jul 3, 2014 10:39 AM Subject: xml2rfc v2 transition To: "IETF Announcement List" Cc: As a reminder to the community, the RFC Editor is transitioning completely to xml2rfc v2 for processing XML source for drafts this month. If your XML file does not parse using xml2rfc v2, it may be returned to you with a request to update the XML. Since we do appreciate receiving XML source for the drafts which are approved for publication, we encourage those who are still working with a tool-chain based on xml2rfc v1 (the TCL releases) to transition to v2 (the Python releases). The xml2rfc v2 processor is more strict about handling non-wellformed or invalid XML. Please see for more detail regarding strict handling of XML. The RFC Editor will continue to accept XML source for Internet-Drafts created using v1 that were approved for publication by 30 June 2014. Authors may also continue to submit documents in nroff or txt if an XML source is not available. The original announcement is available here: If you have questions about xml2rfc v2, please send them to the xml2rfc mailing list . Heather Flanagan, RFC Series Editor --089e0139fe0e22e4fd04fd500bb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
---------- Forwarded message ----------
From:= "RFC Series Editor" <rs= e@rfc-editor.org>
Date: Jul 3, 2014 10:39 AM
Subject: xml2rfc = v2 transition
To: "IETF Announcement List" <ietf-announce@ietf.org>
Cc: <rfc-interest@rfc-editor.org>

As a reminder to the community, the RFC Editor is transitioning completely<= br> to xml2rfc v2 for processing XML source for drafts this month. =C2=A0 If yo= ur XML
file does not parse using xml2rfc v2, it may be returned to you with a
request to update the XML. =C2=A0Since we do appreciate receiving XML sourc= e for
the drafts which are approved for publication, we encourage those who are still working with a tool-chain based on xml2rfc v1 (the TCL releases) to transition to v2 (the Python releases). =C2=A0The xml2rfc v2 processor is m= ore
strict about handling non-wellformed or invalid XML. =C2=A0Please see
<http://xml2rfc.ie= tf.org> for more detail regarding strict handling of XML.

The RFC Editor will continue to accept XML source for Internet-Drafts creat= ed
using v1 that were approved for publication by 30 June 2014.

Authors may also continue to submit documents in nroff or txt if an XML
source is not available.

The original announcement is available here:
<http://www.ietf.org/mail-archive/web/ietf-a= nnounce/current/msg12251.html>

If you have questions about xml2rfc v2, please send them to the xml2rfc
mailing list <xml2rfc@ietf.org&g= t;.

Heather Flanagan, RFC Series Editor

--089e0139fe0e22e4fd04fd500bb8-- From nobody Fri Jul 4 06:50:40 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3CD1B2969; Fri, 4 Jul 2014 06:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Ez6raiqJ3JRx; Fri, 4 Jul 2014 06:50:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 844391B2955; Fri, 4 Jul 2014 06:50:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704135035.14266.19013.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 06:50:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/11I4mlnT_Q4IJYla02gYw87uCdc Cc: nvo3@ietf.org Subject: [nvo3] I-D Action: draft-ietf-nvo3-framework-09.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 13:50:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Virtualization Overlays Working Group of the IETF. Title : Framework for DC Network Virtualization Authors : Marc Lasserre Florin Balus Thomas Morin Nabil Bitar Yakov Rekhter Filename : draft-ietf-nvo3-framework-09.txt Pages : 25 Date : 2014-07-04 Abstract: This document provides a framework for Data Center (DC) Network Virtualization Overlays (NVO3) and it defines a reference model along with logical components required to design a solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nvo3-framework-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-framework-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 7 13:09:49 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A821A0515 for ; Mon, 7 Jul 2014 13:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 zqqiuIZ5U6Dx for ; Mon, 7 Jul 2014 13:09:30 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE351A0A88 for ; Mon, 7 Jul 2014 13:09:26 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s67K9Qal032495; Mon, 7 Jul 2014 13:09:26 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1myy3sg4f4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 07 Jul 2014 13:09:25 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Jul 2014 13:09:24 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Mon, 7 Jul 2014 13:09:24 -0700 From: ramki Krishnan To: "nvo3@ietf.org" Date: Mon, 7 Jul 2014 13:09:23 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aHtco6CSCRSj9SQmnsz9pyqRybAAAHPhg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8587HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-07_03:2014-07-07,2014-07-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407070211 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/iUYcqwiENbsDARii1n8ADyPy_IU Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: [nvo3] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:09:37 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8587HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8587HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Overview of proposed IRTF Network Functions Virtualiz= ation Research Group (NFVRG)

 

Network Function Virtualization (NFV) is a key emerging = area for network operators, hardware and software vendors, cloud service pr= oviders, and in general network practitioners and researchers. This area re= quires exploring new directions and working collaboratively on how to creat= e network services that utilize a virtualized infrastructure. Network funct= ions that are traditionally implemented in dedicated hardware appliances wi= ll need to be decomposed and executed in virtual machines running in data c= enters. One key goal of this new area is to reduce capital and operating ex= penditures for future deployments for networks and associated services. Ano= ther important goal is for the network operators to be able to offer value = added cloud services to their customers. Finally, new business models will = open for the provision of network services.

 

The technologies enabling the= virtualization of network functions are currently in an early stage of, an= d they need researchers to develop new architectures, systems, and software= , and to explore tradeoffs and possibilities for leveraging virtualized inf= rastructure to provide support for network functions. The Network Functions= Virtualization Research Group (NFVRG) will bring together researchers and = grow the community around the world in both academia and industry to explor= e this new research area through workshops, research group meetings etc. at= premier conferences such as IEEE ICC, IEEE Globecom and inviting special i= ssues in well-known journals. Some of the key topics of research include vi= rtualization of fixed and mobile network infrastructures, new network archi= tectures based on virtualized network functions, virtualization of the home= and enterprise network environments, co-existence with non-virtualized inf= rastructure and services, and application to growing areas of concern such = as Internet of Things (IoT) and next generation content distribution.<= /o:p>

 

The= NFVRG will focus on research problems associated with these topics and on = bringing a research community together that can jointly address such proble= ms, concentrating on problems that relate not just to networking but also t= o computing and storage constraints in such environments. It is also hoped = that the outcome of the research will benefit standardization efforts that = can get spawned via IRTF & IETF BoF meetings and/or provide useful inpu= t to other related standards efforts in ETSI or other standards bodies.

 

M= ore details can be found at - http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg<= /a>

 

First face-to-face Meeting in Tor= onto

 

The fi= rst face-to-face meeting of the proposed NFVRG will be held along with the = IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm in th= e Canadian (C) Room (immediately after the SFC meeting). Please let us know= if you have research topics to present during the meeting. Would really ap= preciate active discussions in the mailing list nfvrg@irtf.org.

 

Thanks,

Ram= ki on behalf of the NFVRG co-chairs

= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8587HQ1EXCH01corp_-- From nobody Mon Jul 7 14:07:45 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E291B2912 for ; Mon, 7 Jul 2014 14:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 RcCR4pIZMVeE for ; Mon, 7 Jul 2014 14:07:41 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DFEF1B290B for ; Mon, 7 Jul 2014 14:07:40 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id id10so4564137vcb.16 for ; Mon, 07 Jul 2014 14:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IFUDelL/ySBi+XMT/EMz/ICuX8JcWET3pOJsN+43LlU=; b=ul74ek2OkNF8mhAdkl7vW87n9oN48iZdfIAqGn6pEuW8nkf/mxJ2B1zsaD/ofjGebl ZmzYBm6a3OofemnXSu48skUd1wrMOOPiGROnABEjI/TGDFOTEcHuQ4Q070hg/2aF/QMK IeeqCVg+moi7GW2ESu3M3EUNhB/DT2Q5ngSGmDvcjL98+WHCpaaUh77vCeV8fsVHw1WP vktlJLeLzi/0O+trcVtSoJ8BickCo5WKBSbz3IAgB7zBHUO6ZHS/M/dYKoD57SMLrh3z LnXc5+RZt/P3M99Nshf+W47ut11L/bJs50u+PwVdiCg6ITLWdirzM+vaKI9lYi0Zodwv NuuA== MIME-Version: 1.0 X-Received: by 10.58.19.10 with SMTP id a10mr30305072vee.1.1404767260173; Mon, 07 Jul 2014 14:07:40 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Mon, 7 Jul 2014 14:07:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Jul 2014 14:07:40 -0700 Message-ID: From: Greg Mirsky To: ramki Krishnan Content-Type: multipart/alternative; boundary=e89a8f8393fd88ecb604fda0dd9d Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/tnIbpH4UxcnhUPdyuCjBtj8smT0 Cc: "nvo3@ietf.org" , "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: Re: [nvo3] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:07:43 -0000 --e89a8f8393fd88ecb604fda0dd9d Content-Type: text/plain; charset=UTF-8 Hi Ramki, et. al, very much interested in the making to the meeting but not sure if July 30th is really the same week of the IETF meeting in Toronto. Would it be July 23rd? Regards, Greg On Mon, Jul 7, 2014 at 1:09 PM, ramki Krishnan wrote: > *Overview of proposed IRTF Network Functions Virtualization Research Group > (NFVRG) * > > > > Network Function Virtualization (NFV) is a key emerging area for network > operators, hardware and software vendors, cloud service providers, and in > general network practitioners and researchers. This area requires exploring > new directions and working collaboratively on how to create network > services that utilize a virtualized infrastructure. Network functions that > are traditionally implemented in dedicated hardware appliances will need to > be decomposed and executed in virtual machines running in data centers. One > key goal of this new area is to reduce capital and operating expenditures > for future deployments for networks and associated services. Another > important goal is for the network operators to be able to offer value added > cloud services to their customers. Finally, new business models will open > for the provision of network services. > > > > The technologies enabling the virtualization of network functions are > currently in an early stage of, and they need researchers to develop new > architectures, systems, and software, and to explore tradeoffs and > possibilities for leveraging virtualized infrastructure to provide support > for network functions. The Network Functions Virtualization Research Group > (NFVRG) will bring together researchers and grow the community around the > world in both academia and industry to explore this new research area > through workshops, research group meetings etc. at premier conferences such > as IEEE ICC, IEEE Globecom and inviting special issues in well-known > journals. Some of the key topics of research include virtualization of > fixed and mobile network infrastructures, new network architectures based > on virtualized network functions, virtualization of the home and enterprise > network environments, co-existence with non-virtualized infrastructure and > services, and application to growing areas of concern such as Internet of > Things (IoT) and next generation content distribution. > > > > The NFVRG will focus on research problems associated with these topics and > on bringing a research community together that can jointly address such > problems, concentrating on problems that relate not just to networking but > also to computing and storage constraints in such environments. It is also > hoped that the outcome of the research will benefit standardization efforts > that can get spawned via IRTF & IETF BoF meetings and/or provide useful > input to other related standards efforts in ETSI or other standards bodies. > > > > More details can be found at - > http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg > > > > *First face-to-face Meeting in Toronto* > > > > The first face-to-face meeting of the proposed NFVRG will be held along > with the IETF meeting in Toronto on July 30th Wednesday from 11:30am to > 1:00pm in the Canadian (C) Room (immediately after the SFC meeting). Please > let us know if you have research topics to present during the meeting. > Would really appreciate active discussions in the mailing list > nfvrg@irtf.org. > > > > Thanks, > > Ramki on behalf of the NFVRG co-chairs > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > --e89a8f8393fd88ecb604fda0dd9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ramki, et. al,
very much intere= sted in the making to the meeting but not sure if July 30th is really the s= ame week of the IETF meeting in Toronto. Would it be July 23rd?

Regards,
Greg


On Mon, Jul 7, 2014 at 1:09 PM, ramki Krishnan <ramk@bro= cade.com> wrote:

Over= view of proposed IRTF Network Functions Virtualization Research Group (NFVR= G)

=C2= =A0

Network Function Virtualiza= tion (NFV) is a key emerging area for network operators, hardware and softw= are vendors, cloud service providers, and in general network practitioners = and researchers. This area requires exploring new directions and working co= llaboratively on how to create network services that utilize a virtualized = infrastructure. Network functions that are traditionally implemented in ded= icated hardware appliances will need to be decomposed and executed in virtu= al machines running in data centers. One key goal of this new area is to re= duce capital and operating expenditures for future deployments for networks= and associated services. Another important goal is for the network operato= rs to be able to offer value added cloud services to their customers. Final= ly, new business models will open for the provision of network services.=

=C2=A0

The t= echnologies enabling the virtualization of network functions are currently = in an early stage of, and they need researchers to develop new architecture= s, systems, and software, and to explore tradeoffs and possibilities for le= veraging virtualized infrastructure to provide support for network function= s. The Network Functions Virtualization Research Group (NFVRG) will bring t= ogether researchers and grow the community around the world in both academi= a and industry to explore this new research area through workshops, researc= h group meetings etc. at premier conferences such as IEEE ICC, IEEE Globeco= m and inviting special issues in well-known journals. Some of the key topic= s of research include virtualization of fixed and mobile network infrastruc= tures, new network architectures based on virtualized network functions, vi= rtualization of the home and enterprise network environments, co-existence = with non-virtualized infrastructure and services, and application to growin= g areas of concern such as Internet of Things (IoT) and next generation con= tent distribution.

=C2=A0

The N= FVRG will focus on research problems associated with these topics and on br= inging a research community together that can jointly address such problems= , concentrating on problems that relate not just to networking but also to = computing and storage constraints in such environments. It is also hoped th= at the outcome of the research will benefit standardization efforts that ca= n get spawned via IRTF & IETF BoF meetings and/or provide useful input = to other related standards efforts in ETSI or other standards bodies.

=C2=A0

More = details can be found at - http://trac.tools.ietf.org/group/irtf/tr= ac/wiki/nfvrg

=C2=A0

First face-to-face Meeting in Toronto=

=C2=A0

The first face-to-face meeting of the proposed NFVRG= will be held along with the IETF meeting in Toronto on July 30th Wednesday= from 11:30am to 1:00pm in the Canadian (C) Room (immediately after the SFC= meeting). Please let us know if you have research topics to present during= the meeting. Would really appreciate active discussions in the mailing lis= t nfvrg@irtf.org.

=C2=A0

Thank= s,

Ramki on behalf of the NFVRG co-= chairs


___________________________________= ____________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3


--e89a8f8393fd88ecb604fda0dd9d-- From nobody Mon Jul 7 14:09:22 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E493C1B28E6 for ; Mon, 7 Jul 2014 14:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 5bwR0RlEy5Pn for ; Mon, 7 Jul 2014 14:09:19 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCFF1B28E1 for ; Mon, 7 Jul 2014 14:09:18 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s67L6sRM021346; Mon, 7 Jul 2014 14:09:16 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1myxh306gt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 07 Jul 2014 14:09:15 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Jul 2014 14:09:15 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::f5db:81ae:2a14:f915%12]) with mapi; Mon, 7 Jul 2014 14:09:15 -0700 From: ramki Krishnan To: Greg Mirsky , "nvo3@ietf.org" , "DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com)" , "dilikris@in.ibm.com" Date: Mon, 7 Jul 2014 14:09:14 -0700 Thread-Topic: [nvo3] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aJ34xzGrEx9WYTva2UFBMToX56QAAAurg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB85CAHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-07_03:2014-07-07,2014-07-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407070234 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/tPY8qn125qyv-xd_-U6s_kUsFNk Subject: Re: [nvo3] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:09:21 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB85CAHQ1EXCH01corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywgQWxsLA0KDQpJdCBpcyBvbiBKdWx5IDIzcmQuIEFwb2xvZ2llcyBmb3IgZ2V0dGlu ZyB0aGUgZGF0ZSB3cm9uZy4NCg0KVGhhbmtzLA0KUmFta2kNCg0KRnJvbTogR3JlZyBNaXJza3kg W21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIEp1bHkgMDcsIDIw MTQgMjowOCBQTQ0KVG86IHJhbWtpIEtyaXNobmFuDQpDYzogbnZvM0BpZXRmLm9yZzsgRElFR08g TE9QRVogR0FSQ0lBIChkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tKTsgZGlsaWtyaXNAaW4u aWJtLmNvbQ0KU3ViamVjdDogUmU6IFtudm8zXSBQcm9wb3NlZCBJUlRGIE5ldHdvcmsgRnVuY3Rp b25zIFZpcnR1YWxpemF0aW9uIFJlc2VhcmNoIEdyb3VwIChORlZSRykgLSBmaXJzdCBmYWNlLXRv LWZhY2UgbWVldGluZyBhdCBUb3JvbnRvDQoNCkhpIFJhbWtpLCBldC4gYWwsDQp2ZXJ5IG11Y2gg aW50ZXJlc3RlZCBpbiB0aGUgbWFraW5nIHRvIHRoZSBtZWV0aW5nIGJ1dCBub3Qgc3VyZSBpZiBK dWx5IDMwdGggaXMgcmVhbGx5IHRoZSBzYW1lIHdlZWsgb2YgdGhlIElFVEYgbWVldGluZyBpbiBU b3JvbnRvLiBXb3VsZCBpdCBiZSBKdWx5IDIzcmQ/DQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBNb24s IEp1bCA3LCAyMDE0IGF0IDE6MDkgUE0sIHJhbWtpIEtyaXNobmFuIDxyYW1rQGJyb2NhZGUuY29t PG1haWx0bzpyYW1rQGJyb2NhZGUuY29tPj4gd3JvdGU6DQpPdmVydmlldyBvZiBwcm9wb3NlZCBJ UlRGIE5ldHdvcmsgRnVuY3Rpb25zIFZpcnR1YWxpemF0aW9uIFJlc2VhcmNoIEdyb3VwIChORlZS RykNCg0KTmV0d29yayBGdW5jdGlvbiBWaXJ0dWFsaXphdGlvbiAoTkZWKSBpcyBhIGtleSBlbWVy Z2luZyBhcmVhIGZvciBuZXR3b3JrIG9wZXJhdG9ycywgaGFyZHdhcmUgYW5kIHNvZnR3YXJlIHZl bmRvcnMsIGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJzLCBhbmQgaW4gZ2VuZXJhbCBuZXR3b3JrIHBy YWN0aXRpb25lcnMgYW5kIHJlc2VhcmNoZXJzLiBUaGlzIGFyZWEgcmVxdWlyZXMgZXhwbG9yaW5n IG5ldyBkaXJlY3Rpb25zIGFuZCB3b3JraW5nIGNvbGxhYm9yYXRpdmVseSBvbiBob3cgdG8gY3Jl YXRlIG5ldHdvcmsgc2VydmljZXMgdGhhdCB1dGlsaXplIGEgdmlydHVhbGl6ZWQgaW5mcmFzdHJ1 Y3R1cmUuIE5ldHdvcmsgZnVuY3Rpb25zIHRoYXQgYXJlIHRyYWRpdGlvbmFsbHkgaW1wbGVtZW50 ZWQgaW4gZGVkaWNhdGVkIGhhcmR3YXJlIGFwcGxpYW5jZXMgd2lsbCBuZWVkIHRvIGJlIGRlY29t cG9zZWQgYW5kIGV4ZWN1dGVkIGluIHZpcnR1YWwgbWFjaGluZXMgcnVubmluZyBpbiBkYXRhIGNl bnRlcnMuIE9uZSBrZXkgZ29hbCBvZiB0aGlzIG5ldyBhcmVhIGlzIHRvIHJlZHVjZSBjYXBpdGFs IGFuZCBvcGVyYXRpbmcgZXhwZW5kaXR1cmVzIGZvciBmdXR1cmUgZGVwbG95bWVudHMgZm9yIG5l dHdvcmtzIGFuZCBhc3NvY2lhdGVkIHNlcnZpY2VzLiBBbm90aGVyIGltcG9ydGFudCBnb2FsIGlz IGZvciB0aGUgbmV0d29yayBvcGVyYXRvcnMgdG8gYmUgYWJsZSB0byBvZmZlciB2YWx1ZSBhZGRl ZCBjbG91ZCBzZXJ2aWNlcyB0byB0aGVpciBjdXN0b21lcnMuIEZpbmFsbHksIG5ldyBidXNpbmVz cyBtb2RlbHMgd2lsbCBvcGVuIGZvciB0aGUgcHJvdmlzaW9uIG9mIG5ldHdvcmsgc2VydmljZXMu DQoNClRoZSB0ZWNobm9sb2dpZXMgZW5hYmxpbmcgdGhlIHZpcnR1YWxpemF0aW9uIG9mIG5ldHdv cmsgZnVuY3Rpb25zIGFyZSBjdXJyZW50bHkgaW4gYW4gZWFybHkgc3RhZ2Ugb2YsIGFuZCB0aGV5 IG5lZWQgcmVzZWFyY2hlcnMgdG8gZGV2ZWxvcCBuZXcgYXJjaGl0ZWN0dXJlcywgc3lzdGVtcywg YW5kIHNvZnR3YXJlLCBhbmQgdG8gZXhwbG9yZSB0cmFkZW9mZnMgYW5kIHBvc3NpYmlsaXRpZXMg Zm9yIGxldmVyYWdpbmcgdmlydHVhbGl6ZWQgaW5mcmFzdHJ1Y3R1cmUgdG8gcHJvdmlkZSBzdXBw b3J0IGZvciBuZXR3b3JrIGZ1bmN0aW9ucy4gVGhlIE5ldHdvcmsgRnVuY3Rpb25zIFZpcnR1YWxp emF0aW9uIFJlc2VhcmNoIEdyb3VwIChORlZSRykgd2lsbCBicmluZyB0b2dldGhlciByZXNlYXJj aGVycyBhbmQgZ3JvdyB0aGUgY29tbXVuaXR5IGFyb3VuZCB0aGUgd29ybGQgaW4gYm90aCBhY2Fk ZW1pYSBhbmQgaW5kdXN0cnkgdG8gZXhwbG9yZSB0aGlzIG5ldyByZXNlYXJjaCBhcmVhIHRocm91 Z2ggd29ya3Nob3BzLCByZXNlYXJjaCBncm91cCBtZWV0aW5ncyBldGMuIGF0IHByZW1pZXIgY29u ZmVyZW5jZXMgc3VjaCBhcyBJRUVFIElDQywgSUVFRSBHbG9iZWNvbSBhbmQgaW52aXRpbmcgc3Bl Y2lhbCBpc3N1ZXMgaW4gd2VsbC1rbm93biBqb3VybmFscy4gU29tZSBvZiB0aGUga2V5IHRvcGlj cyBvZiByZXNlYXJjaCBpbmNsdWRlIHZpcnR1YWxpemF0aW9uIG9mIGZpeGVkIGFuZCBtb2JpbGUg bmV0d29yayBpbmZyYXN0cnVjdHVyZXMsIG5ldyBuZXR3b3JrIGFyY2hpdGVjdHVyZXMgYmFzZWQg b24gdmlydHVhbGl6ZWQgbmV0d29yayBmdW5jdGlvbnMsIHZpcnR1YWxpemF0aW9uIG9mIHRoZSBo b21lIGFuZCBlbnRlcnByaXNlIG5ldHdvcmsgZW52aXJvbm1lbnRzLCBjby1leGlzdGVuY2Ugd2l0 aCBub24tdmlydHVhbGl6ZWQgaW5mcmFzdHJ1Y3R1cmUgYW5kIHNlcnZpY2VzLCBhbmQgYXBwbGlj YXRpb24gdG8gZ3Jvd2luZyBhcmVhcyBvZiBjb25jZXJuIHN1Y2ggYXMgSW50ZXJuZXQgb2YgVGhp bmdzIChJb1QpIGFuZCBuZXh0IGdlbmVyYXRpb24gY29udGVudCBkaXN0cmlidXRpb24uDQoNClRo ZSBORlZSRyB3aWxsIGZvY3VzIG9uIHJlc2VhcmNoIHByb2JsZW1zIGFzc29jaWF0ZWQgd2l0aCB0 aGVzZSB0b3BpY3MgYW5kIG9uIGJyaW5naW5nIGEgcmVzZWFyY2ggY29tbXVuaXR5IHRvZ2V0aGVy IHRoYXQgY2FuIGpvaW50bHkgYWRkcmVzcyBzdWNoIHByb2JsZW1zLCBjb25jZW50cmF0aW5nIG9u IHByb2JsZW1zIHRoYXQgcmVsYXRlIG5vdCBqdXN0IHRvIG5ldHdvcmtpbmcgYnV0IGFsc28gdG8g Y29tcHV0aW5nIGFuZCBzdG9yYWdlIGNvbnN0cmFpbnRzIGluIHN1Y2ggZW52aXJvbm1lbnRzLiBJ dCBpcyBhbHNvIGhvcGVkIHRoYXQgdGhlIG91dGNvbWUgb2YgdGhlIHJlc2VhcmNoIHdpbGwgYmVu ZWZpdCBzdGFuZGFyZGl6YXRpb24gZWZmb3J0cyB0aGF0IGNhbiBnZXQgc3Bhd25lZCB2aWEgSVJU RiAmIElFVEYgQm9GIG1lZXRpbmdzIGFuZC9vciBwcm92aWRlIHVzZWZ1bCBpbnB1dCB0byBvdGhl ciByZWxhdGVkIHN0YW5kYXJkcyBlZmZvcnRzIGluIEVUU0kgb3Igb3RoZXIgc3RhbmRhcmRzIGJv ZGllcy4NCg0KTW9yZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBhdCAtIGh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL2dyb3VwL2lydGYvdHJhYy93aWtpL25mdnJnDQoNCkZpcnN0IGZhY2UtdG8tZmFj ZSBNZWV0aW5nIGluIFRvcm9udG8NCg0KVGhlIGZpcnN0IGZhY2UtdG8tZmFjZSBtZWV0aW5nIG9m IHRoZSBwcm9wb3NlZCBORlZSRyB3aWxsIGJlIGhlbGQgYWxvbmcgd2l0aCB0aGUgSUVURiBtZWV0 aW5nIGluIFRvcm9udG8gb24gSnVseSAzMHRoIFdlZG5lc2RheSBmcm9tIDExOjMwYW0gdG8gMTow MHBtIGluIHRoZSBDYW5hZGlhbiAoQykgUm9vbSAoaW1tZWRpYXRlbHkgYWZ0ZXIgdGhlIFNGQyBt ZWV0aW5nKS4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIHJlc2VhcmNoIHRvcGljcyB0 byBwcmVzZW50IGR1cmluZyB0aGUgbWVldGluZy4gV291bGQgcmVhbGx5IGFwcHJlY2lhdGUgYWN0 aXZlIGRpc2N1c3Npb25zIGluIHRoZSBtYWlsaW5nIGxpc3QgbmZ2cmdAaXJ0Zi5vcmc8bWFpbHRv Om5mdnJnQGlydGYub3JnPi4NCg0KVGhhbmtzLA0KUmFta2kgb24gYmVoYWxmIG9mIHRoZSBORlZS RyBjby1jaGFpcnMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm52bzMgbWFpbGluZyBsaXN0DQpudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQoNCg== --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB85CAHQ1EXCH01corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpIEdyZWcs IEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkl0IGlzIG9uIEp1bHkgMjM8c3VwPnJkPC9zdXA+LiBB cG9sb2dpZXMgZm9yIGdldHRpbmcgdGhlIGRhdGUgd3JvbmcuPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPlJhbWtpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gR3JlZyBN aXJza3kgW21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb21dIDxicj48Yj5TZW50OjwvYj4gTW9u ZGF5LCBKdWx5IDA3LCAyMDE0IDI6MDggUE08YnI+PGI+VG86PC9iPiByYW1raSBLcmlzaG5hbjxi cj48Yj5DYzo8L2I+IG52bzNAaWV0Zi5vcmc7IERJRUdPIExPUEVaIEdBUkNJQSAoZGllZ28uci5s b3BlekB0ZWxlZm9uaWNhLmNvbSk7IGRpbGlrcmlzQGluLmlibS5jb208YnI+PGI+U3ViamVjdDo8 L2I+IFJlOiBbbnZvM10gUHJvcG9zZWQgSVJURiBOZXR3b3JrIEZ1bmN0aW9ucyBWaXJ0dWFsaXph dGlvbiBSZXNlYXJjaCBHcm91cCAoTkZWUkcpIC0gZmlyc3QgZmFjZS10by1mYWNlIG1lZXRpbmcg YXQgVG9yb250bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGkg UmFta2ksIGV0LiBhbCw8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz52ZXJ5IG11Y2ggaW50ZXJlc3RlZCBpbiB0aGUgbWFr aW5nIHRvIHRoZSBtZWV0aW5nIGJ1dCBub3Qgc3VyZSBpZiBKdWx5IDMwdGggaXMgcmVhbGx5IHRo ZSBzYW1lIHdlZWsgb2YgdGhlIElFVEYgbWVldGluZyBpbiBUb3JvbnRvLiBXb3VsZCBpdCBiZSBK dWx5IDIzcmQ/PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlJlZ2FyZHMs PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkdyZWc8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIE1vbiwg SnVsIDcsIDIwMTQgYXQgMTowOSBQTSwgcmFta2kgS3Jpc2huYW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpyYW1rQGJyb2NhZGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmFta0Bicm9jYWRlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 dT5PdmVydmlldyBvZiBwcm9wb3NlZCBJUlRGIE5ldHdvcmsgRnVuY3Rpb25zIFZpcnR1YWxpemF0 aW9uIFJlc2VhcmNoIEdyb3VwIChORlZSRykgPC91PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPk5ldHdv cmsgRnVuY3Rpb24gVmlydHVhbGl6YXRpb24gKE5GVikgaXMgYSBrZXkgZW1lcmdpbmcgYXJlYSBm b3IgbmV0d29yayBvcGVyYXRvcnMsIGhhcmR3YXJlIGFuZCBzb2Z0d2FyZSB2ZW5kb3JzLCBjbG91 ZCBzZXJ2aWNlIHByb3ZpZGVycywgYW5kIGluIGdlbmVyYWwgbmV0d29yayBwcmFjdGl0aW9uZXJz IGFuZCByZXNlYXJjaGVycy4gVGhpcyBhcmVhIHJlcXVpcmVzIGV4cGxvcmluZyBuZXcgZGlyZWN0 aW9ucyBhbmQgd29ya2luZyBjb2xsYWJvcmF0aXZlbHkgb24gaG93IHRvIGNyZWF0ZSBuZXR3b3Jr IHNlcnZpY2VzIHRoYXQgdXRpbGl6ZSBhIHZpcnR1YWxpemVkIGluZnJhc3RydWN0dXJlLiBOZXR3 b3JrIGZ1bmN0aW9ucyB0aGF0IGFyZSB0cmFkaXRpb25hbGx5IGltcGxlbWVudGVkIGluIGRlZGlj YXRlZCBoYXJkd2FyZSBhcHBsaWFuY2VzIHdpbGwgbmVlZCB0byBiZSBkZWNvbXBvc2VkIGFuZCBl eGVjdXRlZCBpbiB2aXJ0dWFsIG1hY2hpbmVzIHJ1bm5pbmcgaW4gZGF0YSBjZW50ZXJzLiBPbmUg a2V5IGdvYWwgb2YgdGhpcyBuZXcgYXJlYSBpcyB0byByZWR1Y2UgY2FwaXRhbCBhbmQgb3BlcmF0 aW5nIGV4cGVuZGl0dXJlcyBmb3IgZnV0dXJlIGRlcGxveW1lbnRzIGZvciBuZXR3b3JrcyBhbmQg YXNzb2NpYXRlZCBzZXJ2aWNlcy4gQW5vdGhlciBpbXBvcnRhbnQgZ29hbCBpcyBmb3IgdGhlIG5l dHdvcmsgb3BlcmF0b3JzIHRvIGJlIGFibGUgdG8gb2ZmZXIgdmFsdWUgYWRkZWQgY2xvdWQgc2Vy dmljZXMgdG8gdGhlaXIgY3VzdG9tZXJzLiBGaW5hbGx5LCBuZXcgYnVzaW5lc3MgbW9kZWxzIHdp bGwgb3BlbiBmb3IgdGhlIHByb3Zpc2lvbiBvZiBuZXR3b3JrIHNlcnZpY2VzLjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPlRoZSB0ZWNobm9sb2dpZXMgZW5hYmxpbmcgdGhlIHZpcnR1YWxpemF0aW9uIG9m IG5ldHdvcmsgZnVuY3Rpb25zIGFyZSBjdXJyZW50bHkgaW4gYW4gZWFybHkgc3RhZ2Ugb2YsIGFu ZCB0aGV5IG5lZWQgcmVzZWFyY2hlcnMgdG8gZGV2ZWxvcCBuZXcgYXJjaGl0ZWN0dXJlcywgc3lz dGVtcywgYW5kIHNvZnR3YXJlLCBhbmQgdG8gZXhwbG9yZSB0cmFkZW9mZnMgYW5kIHBvc3NpYmls aXRpZXMgZm9yIGxldmVyYWdpbmcgdmlydHVhbGl6ZWQgaW5mcmFzdHJ1Y3R1cmUgdG8gcHJvdmlk ZSBzdXBwb3J0IGZvciBuZXR3b3JrIGZ1bmN0aW9ucy4gVGhlIE5ldHdvcmsgRnVuY3Rpb25zIFZp cnR1YWxpemF0aW9uIFJlc2VhcmNoIEdyb3VwIChORlZSRykgd2lsbCBicmluZyB0b2dldGhlciBy ZXNlYXJjaGVycyBhbmQgZ3JvdyB0aGUgY29tbXVuaXR5IGFyb3VuZCB0aGUgd29ybGQgaW4gYm90 aCBhY2FkZW1pYSBhbmQgaW5kdXN0cnkgdG8gZXhwbG9yZSB0aGlzIG5ldyByZXNlYXJjaCBhcmVh IHRocm91Z2ggd29ya3Nob3BzLCByZXNlYXJjaCBncm91cCBtZWV0aW5ncyBldGMuIGF0IHByZW1p ZXIgY29uZmVyZW5jZXMgc3VjaCBhcyBJRUVFIElDQywgSUVFRSBHbG9iZWNvbSBhbmQgaW52aXRp bmcgc3BlY2lhbCBpc3N1ZXMgaW4gd2VsbC1rbm93biBqb3VybmFscy4gU29tZSBvZiB0aGUga2V5 IHRvcGljcyBvZiByZXNlYXJjaCBpbmNsdWRlIHZpcnR1YWxpemF0aW9uIG9mIGZpeGVkIGFuZCBt b2JpbGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZXMsIG5ldyBuZXR3b3JrIGFyY2hpdGVjdHVyZXMg YmFzZWQgb24gdmlydHVhbGl6ZWQgbmV0d29yayBmdW5jdGlvbnMsIHZpcnR1YWxpemF0aW9uIG9m IHRoZSBob21lIGFuZCBlbnRlcnByaXNlIG5ldHdvcmsgZW52aXJvbm1lbnRzLCBjby1leGlzdGVu Y2Ugd2l0aCBub24tdmlydHVhbGl6ZWQgaW5mcmFzdHJ1Y3R1cmUgYW5kIHNlcnZpY2VzLCBhbmQg YXBwbGljYXRpb24gdG8gZ3Jvd2luZyBhcmVhcyBvZiBjb25jZXJuIHN1Y2ggYXMgSW50ZXJuZXQg b2YgVGhpbmdzIChJb1QpIGFuZCBuZXh0IGdlbmVyYXRpb24gY29udGVudCBkaXN0cmlidXRpb24u PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+VGhlIE5GVlJHIHdpbGwgZm9jdXMgb24gcmVzZWFyY2ggcHJv YmxlbXMgYXNzb2NpYXRlZCB3aXRoIHRoZXNlIHRvcGljcyBhbmQgb24gYnJpbmdpbmcgYSByZXNl YXJjaCBjb21tdW5pdHkgdG9nZXRoZXIgdGhhdCBjYW4gam9pbnRseSBhZGRyZXNzIHN1Y2ggcHJv YmxlbXMsIGNvbmNlbnRyYXRpbmcgb24gcHJvYmxlbXMgdGhhdCByZWxhdGUgbm90IGp1c3QgdG8g bmV0d29ya2luZyBidXQgYWxzbyB0byBjb21wdXRpbmcgYW5kIHN0b3JhZ2UgY29uc3RyYWludHMg aW4gc3VjaCBlbnZpcm9ubWVudHMuIEl0IGlzIGFsc28gaG9wZWQgdGhhdCB0aGUgb3V0Y29tZSBv ZiB0aGUgcmVzZWFyY2ggd2lsbCBiZW5lZml0IHN0YW5kYXJkaXphdGlvbiBlZmZvcnRzIHRoYXQg Y2FuIGdldCBzcGF3bmVkIHZpYSBJUlRGICZhbXA7IElFVEYgQm9GIG1lZXRpbmdzIGFuZC9vciBw cm92aWRlIHVzZWZ1bCBpbnB1dCB0byBvdGhlciByZWxhdGVkIHN0YW5kYXJkcyBlZmZvcnRzIGlu IEVUU0kgb3Igb3RoZXIgc3RhbmRhcmRzIGJvZGllcy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5Nb3Jl IGRldGFpbHMgY2FuIGJlIGZvdW5kIGF0IC0gPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvZ3JvdXAvaXJ0Zi90cmFjL3dpa2kvbmZ2cmciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pcnRmL3RyYWMvd2lraS9uZnZyZzwvYT48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48dT5GaXJzdCBmYWNlLXRvLWZhY2UgTWVldGluZyBpbiBUb3JvbnRvPC91 PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPlRoZSBmaXJzdCBmYWNlLXRvLWZhY2UgbWVldGluZyBvZiB0 aGUgcHJvcG9zZWQgTkZWUkcgd2lsbCBiZSBoZWxkIGFsb25nIHdpdGggdGhlIElFVEYgbWVldGlu ZyBpbiBUb3JvbnRvIG9uIEp1bHkgMzB0aCBXZWRuZXNkYXkgZnJvbSAxMTozMGFtIHRvIDE6MDBw bSBpbiB0aGUgQ2FuYWRpYW4gKEMpIFJvb20gKGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBTRkMgbWVl dGluZykuIFBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSByZXNlYXJjaCB0b3BpY3MgdG8g cHJlc2VudCBkdXJpbmcgdGhlIG1lZXRpbmcuIFdvdWxkIHJlYWxseSBhcHByZWNpYXRlIGFjdGl2 ZSBkaXNjdXNzaW9ucyBpbiB0aGUgbWFpbGluZyBsaXN0IDxhIGhyZWY9Im1haWx0bzpuZnZyZ0Bp cnRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5mdnJnQGlydGYub3JnPC9hPi48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz5UaGFua3MsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+UmFta2kg b24gYmVoYWxmIG9mIHRoZSBORlZSRyBjby1jaGFpcnM8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+bnZvMyBtYWls aW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciPm52bzNAaWV0Zi5vcmc8 L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZv MyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bnZvMzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB85CAHQ1EXCH01corp_-- From nobody Mon Jul 7 18:28:54 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9D1B297C for ; Mon, 7 Jul 2014 18:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.05 X-Spam-Level: X-Spam-Status: No, score=-99.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham 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 4oO5wR7ZEh0G for ; Mon, 7 Jul 2014 18:28:49 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 755AC1B289F for ; Mon, 7 Jul 2014 18:28:49 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 3623A18EAF38 for ; Tue, 8 Jul 2014 09:28:39 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id C1AFB72D86B for ; Tue, 8 Jul 2014 09:28:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s681SZiE018050 for ; Tue, 8 Jul 2014 09:28:35 +0800 (GMT-8) (envelope-from gu.zhongyu@zte.com.cn) To: "nvo3@ietf.org" MIME-Version: 1.0 X-KeepSent: EDC76BA6:035EFB48-48257D0F:0007E4E9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gu.zhongyu@zte.com.cn Date: Tue, 8 Jul 2014 09:28:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-08 09:28:32, Serialize complete at 2014-07-08 09:28:32 Content-Type: multipart/alternative; boundary="=_alternative 00081C3248257D0F_=" X-MAIL: mse02.zte.com.cn s681SZiE018050 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/_Xv5ca1QAWfqtswX4SJ6ewz6Ut0 Subject: [nvo3] =?gb2312?b?tPC4tDogUmU6ICBJRVRGIDkwIE5WbzMgU2xvdCBSZXF1?= =?gb2312?b?ZXN0cyAtIFRvcm9udG8=?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 01:28:52 -0000 This is a multipart message in MIME format. --=_alternative 00081C3248257D0F_= Content-Type: text/plain; charset="US-ASCII" Hi Sam, I would like to request a time slot to discuss draft-gu-nvo3-auto-provisioning-reqs-00 and draft-gu-nvo3-virt-edge-auto-discovery-00. Topic: VN auto-provisioning requirements and NVE auto-discovery protocol Draft URL: http://datatracker.ietf.org/doc/draft-gu-nvo3-auto-provisioning-reqs/ http://datatracker.ietf.org/doc/draft-gu-nvo3-virt-edge-auto-discovery/ Brief statement of objective and issues that need to be discussed and resolved via the presentation: VN auto-provisioning discussion and Introduce NVE auto-discovery protocol as a potential protocol for use within NVO3. Request Duration: 10 minutes Speaker: Zhongyu Gu Regards, Zhongyu --=_alternative 00081C3248257D0F_= Content-Type: text/html; charset="US-ASCII"
Hi Sam,
I would like to request a time slot to discuss draft-gu-nvo3-auto-provisioning-reqs-00 and draft-gu-nvo3-virt-edge-auto-discovery-00.
 
Topic: VN auto-provisioning requirements and NVE auto-discovery  protocol
Draft URL: http://datatracker.ietf.org/doc/draft-gu-nvo3-auto-provisioning-reqs/
                    http://datatracker.ietf.org/doc/draft-gu-nvo3-virt-edge-auto-discovery/                  
Brief statement of objective and issues that need to be discussed and resolved via the presentation:
         VN auto-provisioning discussion and Introduce NVE auto-discovery protocol as a potential protocol for use within NVO3.
Request Duration: 10 minutes
Speaker:  Zhongyu Gu
 
Regards,
Zhongyu

--=_alternative 00081C3248257D0F_=-- From nobody Mon Jul 7 19:32:53 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8871B2A01 for ; Mon, 7 Jul 2014 19:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 49Mvrx4fm30X for ; Mon, 7 Jul 2014 19:32:51 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F461B29FB for ; Mon, 7 Jul 2014 19:32:51 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id eu11so6446769pac.19 for ; Mon, 07 Jul 2014 19:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=1pGVLWQ/Pj/Um6qvfOKVZqzgZ4csF2JXc7jiDX7qZjU=; b=SqfXYLEkVBimAuHGs1buJHlRDOVd4pU+RhA5FdXgg7Z94wrIkqfH/UstyPliYW4COI vvnoWPr/lA8Ud6dJl0tTORUXq+IvLELoTrC0N9x/2FwPntHhHYFhZ5lWZ7i4BD/e7c1E l7SyGSdgJJiHOL+nM+DYIDn0/qewYp83dJ32AKCMJ+O9HUFd8Qgt/A99+qXvEDnNLgOm IZxaKoxTR+ij56GaqUek0CNm78nUDAFIQqmmxCc6M30aWwCttP9eX5uipTG1mSzHeIiu 6KeAczGpx+grsMRAfExJXVBkdjJ5DKIB8BGUkZbteLSqc2dd/+BX63KFEilayV676u5P xkAg== X-Received: by 10.68.225.74 with SMTP id ri10mr6936970pbc.116.1404786770652; Mon, 07 Jul 2014 19:32:50 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id n12sm22184887pdj.29.2014.07.07.19.32.48 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Jul 2014 19:32:50 -0700 (PDT) From: "Lizhong Jin" To: Date: Tue, 8 Jul 2014 10:32:46 +0800 Message-ID: <007d01cf9a54$e9400110$bbc00330$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01CF9A97.F7642B70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+aU1Ie0naUNLB0QyS/HXyBla5gWg== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/gqvnuCXb6zvU9CsYDDO_poV5zro Cc: nvo3@ietf.org Subject: [nvo3] Comments of draft-liu-nvo3-ps-vxlan-perfomance-00 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 02:32:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007E_01CF9A97.F7642B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi authors, I do not quite understand the purpose of this draft. But the performance issues listed in section 3.1 may not true if the newly designed NIC is applied. Some vendors are designing NIC to support VXLAN offload, and could provide very good performance. The performance issue will not be a problem with the emerging of newly designed NIC. In the draft, you did not point out the tested traffic type. The large TCP packet performance is a very important test point. You could refer to link http://networkheresy.com/2012/06/08/the-overhead-of-software-tunneling/. Regards Lizhong ------=_NextPart_000_007E_01CF9A97.F7642B70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = authors,

I do not quite understand = the purpose of this draft. But the performance issues listed in section = 3.1 may not true if the newly designed NIC is applied. Some vendors are = designing NIC to support VXLAN offload, and could provide very good = performance. The performance issue will not be a problem with the = emerging of newly designed NIC.

In = the draft, you did not point out the tested traffic type. The large TCP = packet performance is a very important test point. You could refer to = link http://networkheresy.com/2012/06/08/the-overhead-of-software-tunn= eling/.

 

Regards

Lizhong =

------=_NextPart_000_007E_01CF9A97.F7642B70-- From nobody Tue Jul 8 05:07:55 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5D21B2A74; Tue, 8 Jul 2014 05:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 FvoSnrG_vdKh; Tue, 8 Jul 2014 05:07:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68741B280E; Tue, 8 Jul 2014 05:07:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT19379; Tue, 08 Jul 2014 12:07:08 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 13:07:06 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 20:07:03 +0800 From: Qin Wu To: "Tissa Senevirathne (tsenevir)" , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8A== Date: Tue, 8 Jul 2014 12:07:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84580501nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/YrWx3aDaujrhaP3ZpmQR2HvJ0T8 Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 12:07:13 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84580501nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFRpc3NhOg0KVGhlcmUgYXJlIG1hbnkgb3B0aW9ucyBmb3IgU0ZDIE9BTSwgQkZEIGV4dGVu c2lvbiwgR2VuZXJpYyBIZWFkZXIgZXh0ZW5zaW9uLCBHZW5lcmljIFRMViBleHRlbnNpb24uDQpV bmxpa2Ugb3RoZXIgZXhpc3RpbmcgT0FNIHByb3RvY29scywgbWVjaGFuaXNtcyBhbmQgdG9vbHMs IFNGQyBuZWVkIHRvIGFkZHJlc3MgT0FNIGZvciB0aGUgdGVjaG5vbG9neSB0aGF0IGlzIGFib3Zl IGxheWVyIDMuDQpTRkMgaGF2ZW6hr3QgZGV2ZWxvcGVkIE9BTSBwcm90b2NvbCB5ZXQgYXQgdGhl IHRvcCBvZiBsYXllciAzLg0KDQpCZWZvcmUgdGhleSBkZXZlbG9waW5nIE9BTSBwcm90b2NvbCwg dGhleSBuZWVkIHRvIGZpZ3VyZSBvdXQgd2hldGhlciB0aGV5IG5lZWQgdG8gZGV2ZWxvcCB0ZWNo bm9sb2d5IGRlcGVuZGVudCBPQU0gcHJvdG9jb2wsDQpPciB0ZWNobm9sb2d5IGluZGVwZW5kZW50 IE9BTSBwcm90b2NvbCBzaW5jZSBTRkMgT0FNIGFuZCBPdmVybGF5IE9BTSBzaGFyZSBhIGxvdCBv ZiBzaW1pbGFyaXRpZXMoZS5nLiwgYm90aCBjYW4gdXNlIG92ZXJsYXkgdGVjaG5vbG9neSB0byBz dGl0Y2ggYSBzZXQgb2Ygb3ZlcmxheSBub2RlIG9yIHNlcnZpY2Ugbm9kZSB0byBmb3JtIHRoZSBl bmQgdG8gZW5kIHBhdGgpLiBXaHkgbm90IGJ1aWxkIG9uZSBwcm90b2NvbCB0byBzdXBwb3J0IGJv dGg/DQoNClRoYXShr3Mgd2h5IHdlIGJyaW5nIHVwIHRyYW5zcG9ydCBpbmRlcGVuZGVudCBPQU0g Y292ZXJpbmcgdmFyaW91cyBoZXRlcm9nZW5lb3VzIG5ldHdvcmsgdGVjaG5vbG9naWVzIGFuZCBw cm9wb3NlIHRvIGNvbnNvbGlkYXRlIE9BTSBpbiBib3RoDQpNYW5hZ2VtZW50IHBsYW5lIGFuZCBk YXRhIHBsYW5lLg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3ctb3BzYXdnLW11 bHRpLWxheWVyLW9hbS0wMg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2luZy1v cHNhd2ctdGltZS1tdWx0aS1sYXllci1vYW0tdXNlLWNhc2UtMDEudHh0DQoNClJlZ2FyZGluZyBm bG93LWVudHJvcHksIHdoeSBub3QgcmV1c2UgZW50cm9weSBtZWNoYW5pc21zIGluIHRoZSBleGlz dGluZyB1bmRlcmx5aW5nIHRyYW5zcG9ydC4gSG93IGlzIGZsb3cgZW50cm9weSBkaWZmZXJlbnQg ZnJvbSBFQ01QIGNob2ljZSB5b3UgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0Lg0KSWYgbXkgdW5kZXJz dGFuZGluZyBpcyBjb3JyZWN0LCBJRUVFIDgwMi4xYWcgb25seSBzdXBwb3J0IEVxdWFsIENvc3Qg VHJlZSAoRUNUKSBtZWNoYW5pc20gaW5zdGVhZCBvZiBFQ01QLCBJRUVFODAyLjFRYnAgc3VwcG9y dCBFQ01QLA0KQXJlIHlvdSBwcm9wb3NpbmcgdG8gY29tYmluZSBFQ1Qgc3VwcG9ydGVkIGJ5IElF RUUgODAyLjFhZyB3aXRoIEVDTVAgc3VwcG9ydGVkIGJ5IElFRUUgODAyLjFRYnAgYW5kIHVzZSB0 aGVtIHRvZ2V0aGVyIGF0IHRoZSBzYW1lIHRpbWUgaW4gdGhlIHNhbWUgbmV0d29yaz8NCg0KQWxz byBCRkQgYW5kIElFRUUgODAyLjFhZyBDRk0gc2hhcmUgYSBsb3Qgb2YgY29tbW9uYWxpdHksIGUu Zy4sIENDTS1pbnRlcnZhbCwgQkZEIGludGVydmFsLiBJZiB3ZSBpbnRlZ3JhdGUgdGhlbSB0b2dl dGhlciwgd2UgcmVhbGx5IG5lZWQgdG8gdGhpbmsgYWJvdXQgaG93IHRvIGludGVncmF0ZSB0aGVt IHRvZ2V0aGVyIGluIHRoZSBtYW5hZ2VtZW50IHBsYW5lLiBJcyB0aGVyZSBhbnkgY29tbW9uIGNv bXBvbmVudCB3ZSBjYW4gZGVmaW5lIGZvciBib3RoPyBIb3cgd2UgZGVmaW5lIHRoZXNlIGNvbXBv bmVudCBhbmQgbWFrZSB0aGVtIG1vcmUgZXh0ZW5zaWJsZS4NCg0KUmVnYXJkcyENCi1RaW4NCrei vP7IyzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikgW21haWx0bzp0c2VuZXZpckBjaXNj by5jb21dDQq3osvNyrG85DogMjAxNMTqNtTCMzDI1SAwOjIwDQrK1bz+yMs6IFFpbiBXdTsgdGlt ZUBpZXRmLm9yZw0Ks63LzTogbmV0bW9kQGlldGYub3JnOyBudm8zQGlldGYub3JnOyB0cmlsbEBp ZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZw0K1vfM4jogUkU6IFlBTkcg bW9kZWxzIGZvciBPQU0NCg0KSGkgUWluDQoNClRoZXJlIGFyZSBzZXZlcmFsIHdheSB0aGlzIGlz IGFwcGxpY2FibGUgdG8gU0ZDDQoNCg0KMS4gICAgICAgU0ZDIGlzIHVuZGVybGF5ZXIgaW5kZXBl bmRlbnQgLCB3aGljaCBtZWFucyBpdCBjYW4gaGF2ZSBhbGwgc29ydHMgb2YgZW5jYXAgdHlwZXMg dW5kZXJuZWF0aCwgdGhlIG1vZGVsIHByZXNlbnRlZCBpbiB0aXNzYS1uZXRtb2Qtb2FtLCBhZGRy ZXNzIGV4YWN0bHkgdGhhdCBpc3N1ZS4gSW5zdGVhZCBvZiByZS1pbnZlbnRpbmcgYW5kIHJlLWlt cGxlbWVudGluZyB2YXJpb3VzIGRpZmZlcmVudCBPQU0gdGhlIGRyYWZ0IHByb3Bvc2UgdG8gaW50 ZWdyYXRlIHRoZW0gYXQgdGhlIG1hbmFnZW1lbnQgbGF5ZXIuDQoNCjIuICAgICAgIEluIHRoaXMg ZHJhZnQgd2UgZGVmaW5lIGEgZmxvdy1lbnRyb3B5IGFzIGFuIG9wYXF1ZSBlbGVtZW50IHRoYXQg ZWFjaCBvZiB0aGUgdGVjaG5vbG9neSB0eXBlIGNhbiBzcGVjaWZ5IGFuZCBpbmNsdWRlLiBJZiB3 ZSBsb29rIGF0IGRyYWZ0LXF1aW5uLXNmYy1uc2gtMDIudHh0LCBpdCBkZWZpbmUgYSBibG9jayB0 aGF0IHNwZWNpZmllcyBTRkMuIFNGQyB2ZXJzaW9uIG9mIFlBTkcgIGNhbiBzcGVjaWZ5IHRoaXMg YXMgcGFydCBvZiBpdHMgZmxvdyBlbnRyb3B5LiBUaGUgYmVhdXR5IGlzIHRoYXQgaXQgaXMgYWxs IHVwIHRvIHRoZSB0ZWNobm9sb2d5IHRvIHNwZWNpZnkgdGhhdCAoc2l6ZSBhbmQgc2hhcGUgaXMg dGVjaG5vbG9neSBkZXBlbmRlbnQpIGFuZCBiYXNlIG1vZGVsIGlzIHN0aWxsIGludGFjdC4NCg0K V2l0aCB0aGUgYWJvdmUgaW4gbWluZCAsIGNhbiB5b3UgcGxlYXNlIHJldmlldyBkcmFmdC10aXNz YS1uZXRtb2Qtb2FtIGFuZCBzZWUgaXQgaXMgZmxleGlibGUgYW5kIGV4dGVuc2libGUgZW5vdWdo IHRvIGZvciB0aGUgcHVycG9zZS4gSWYgdGhpbmdzIGFyZSBtaXNzaW5nIHdlIGNhbiBhZGQgYW5k IGV4dGVuZC4NCg0KSSBoYXZlIHJlcXVlc3RlZCBuZXRtb2QgV0cgY2hhaXJzIGZvciBhIHByZXNl bnRhdGlvbiBzbG90IGZvciBmdXJ0aGVyIGRpc2N1c3Npb24gb2YgdGhlIGRyYWZ0Lg0KDQpGcm9t OiBRaW4gV3UgW21haWx0bzpiaWxsLnd1QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdW5l IDEwLCAyMDE0IDk6MjIgUE0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsgdGlt ZUBpZXRmLm9yZzxtYWlsdG86dGltZUBpZXRmLm9yZz4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+ OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxt YWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpLCBUaXNzYToNClRo YW5rcyBmb3IgaW5pdGlhdGluZyBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMuDQpVbmlmaWVkIE9B TSBmb3IgbXVsdGktTGF5ZXIgbmV0d29yayBpcyBhIGdvb2QgaWRlYSB0byBtZS4NCmRyYWZ0LXd3 LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDAgd2UgcHJvcG9zZWQgaW4gb3BzYXdnIGxhaWQgb3V0 IHRoZSBhbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtLg0KVGhlIHF1ZXN0aW9u IHRvIGRyYWZ0LXRpc3NhLW5ldG1vZC1vYW0gaXMNCkkgYW0gd29uZGVyaW5nIGhvdyB0aGlzIGdl bmVyaWMgWWFuZyBNb2RlbCBjYW4gYmUgYXBwbGllZCB0byBTRkMgZW52aXJvbm1lbnQ/DQpIb3cg ZG8geW91IHN1cHBvcnQgdGhlIGNhc2Ugd2hlcmUgdHdvIGVuZHBvaW50cyBzdXBwb3J0IGRpZmZl cmVudCBsYXllciBPQU0gb3IgZG9lc26hr3Qgc3VwcG9ydCBhbnkgT0FNIGF0IHRoYXQgbGF5ZXIu DQoNCkJUVzogSSBoYXZlIGNjoa9lZCB0aW1lIG1haWxpbmcgbGlzdCBzaW5jZSBJIGJlbGlldmUg dGhpcyBtYWlsaW5nIGxpc3QgaXMgcHVycG9zZWQgdG8gbG9vayBmb3IgZ2VuZXJpYyBhbmQgaW50 ZWdyYXRlZCBPQU0gY292ZXJpbmcgdmFyaW91cyBoZXRlcm9nZW5lb3VzIG5ldHdvcmtpbmcgdGVj aG5vbG9naWVzLg0KUmVnYXJkcyENCi1RaW4NCreivP7IyzogbmV0bW9kIFttYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCrei y83KsbzkOiAyMDE0xOo21MIxMcjVIDM6MDMNCsrVvP7IyzogbmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPjsg dHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPjsgbDJ2cG5AaWV0Zi5vcmc8bWFp bHRvOmwydnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5v cmc+DQrW98ziOiBbbmV0bW9kXSBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkFsbA0KDQpXZSBoYXZl IHB1Ymxpc2hlZCBZQU5HIG1vZGVsIGZvciBPQU0uICMxIGRyYWZ0IGJlbG93IHBsYWNlIHRoZSBn ZW5lcmljIGZyYW1ld29yayBmb3IgT0FNLCB0aGF0IGNhbiBiZSBhdWdtZW50ZWQgZm9yIGRpZmZl cmVudCB0ZWNobm9sb2dpZXMuICMyIGFuZCAjMyBhcmUgYXBwbGljYXRpb24gb2YgdGhlIGNvbmNl cHQgdG8gTlZPMyBhbmQgVFJJTEwsDQoNCg0KMS4gICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC10aXNzYS1uZXRtb2Qtb2FtLw0KDQoyLiAgICAgICBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFuZy1vYW0vDQoNCjMuICAg ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2EtdHJpbGwteWFu Zy1vYW0vDQoNClBsZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29tbWVudHMNCg0KVGhhbmtz DQpUaXNzYQ0KDQoNCg== --_000_B8F9A780D330094D99AF023C5877DABA84580501nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Tissa:

There are many options for SFC OAM, BFD extension, Generic Header= extension, Generic TLV extension.

Unlike other existing OAM protocols, mechanisms and tools, SFC ne= ed to address OAM for the technology that is above layer 3.

SFC haven=A1=AFt developed OAM protocol yet at the top of layer 3= .

 

Before they developing OAM protocol, they need to figure out whet= her they need to develop technology dependent OAM protocol,

Or technology independent OAM protocol since SFC OAM and Overlay = OAM share a lot of similarities(e.g., both can use overlay technology to st= itch a set of overlay node or service node to form the end to end path). Why not build one protocol to support b= oth?

 

That=A1=AFs why we bring up transport independent OAM covering va= rious heterogeneous network technologies and propose to consolidate OAM in = both

Management plane and data plane.

http://tools.ietf.org/html/draft= -ww-opsawg-multi-layer-oam-02

http://tools= .ietf.org/html/draft-king-opsawg-time-multi-layer-oam-use-case-01.txt

 

Regarding flow-entropy, why not reuse entropy mechanisms in the e= xisting underlying transport. How is flow entropy different from ECMP choic= e you proposed in the draft.

If my understanding is correct, IEEE 802.1ag only support Equal C= ost Tree (ECT) mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are you proposing to combine ECT supported by IEEE 802.1ag with E= CMP supported by IEEE 802.1Qbp and use them together at the same time in th= e same network?

 

Also BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., C= CM-interval, BFD interval. If we integrate them together, we really need to= think about how to integrate them together in the management plane. Is there any common component we can define for b= oth? How we define these component and make them more extensible.

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Tissa S= enevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ie= tf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin<= o:p>

&n= bsp;

There a= re several way this is applicable to SFC

&n= bsp;

= 1.       SFC is underlayer independent , which means it can have all sorts of encap= types underneath, the model presented in tissa-netmod-oam, address exactly= that issue. Instead of re-inventing and re-implementing various different OAM the draft propose to integrate t= hem at the management layer.

= 2.       In this draft we define a flow-entropy as an opaque element that each of t= he technology type can specify and include. If we look at draft-quinn-sfc-n= sh-02.txt, it define a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entrop= y. The beauty is that it is all up to the technology to specify that (size = and shape is technology dependent) and base model is still intact.

&n= bsp;

With th= e above in mind , can you please review draft-tissa-netmod-oam and see it i= s flexible and extensible enough to for the purpose. If things are missing = we can add and extend.

&n= bsp;

I have = requested netmod WG chairs for a presentation slot for further discussion o= f the draft.  

&n= bsp;

From: Qin Wu [mailto:= bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, Tissa:

Thanks for initiating discussion on this topic.=

Unified OAM for multi-Layer network is a good idea to me.

draft-ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out= the an initial description of the problem.

The question to draft-= tissa-netmod-oam is

I am wondering how this generic Yang Model can be applied to SFC = environment?

How do you support the case where two endpoints support different= layer OAM or doesn=A1=AFt support any OAM at that layer.=

 

BTW: I have cc=A1=AFed time mailing list since I believe this mai= ling list is purposed to look for generic and integrated OAM covering vario= us heterogeneous networking technologies.

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: netmod = [mailto:netmod-bounces@ietf.org<= /a>] =B4=FA= =B1=ED Tissa Senevirathne (tsenevir)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for OAM

 

All

 

We have published YANG model fo= r OAM. #1 draft below place the generic framework for OAM, that can be augm= ented for different technologies. #2 and #3 are application of the concept = to NVO3 and TRILL,

 

1. &nbs= p;     http://datatracker.ietf.org/do= c/draft-tissa-netmod-oam/

2. &nbs= p;     http://datatracker.ietf.org= /doc/draft-tissa-nvo3-yang-oam/

3. &nbs= p;     http://datatracker.ietf.or= g/doc/draft-tissa-trill-yang-oam/

 

Please review and share your co= mments

 

Thanks

Tissa

 

 

--_000_B8F9A780D330094D99AF023C5877DABA84580501nkgeml501mbschi_-- From nobody Tue Jul 8 07:12:37 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7BD1B2AED for ; Tue, 8 Jul 2014 07:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 w1SWhsdR2eW2 for ; Tue, 8 Jul 2014 07:12:24 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82931B2AEC for ; Tue, 8 Jul 2014 07:12:24 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s68E0mWT014328; Tue, 8 Jul 2014 07:12:24 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1n04k5891m-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 08 Jul 2014 07:12:24 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 07:12:23 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::f5db:81ae:2a14:f915%12]) with mapi; Tue, 8 Jul 2014 07:12:23 -0700 From: ramki Krishnan To: "'nvo3@ietf.org'" Date: Tue, 8 Jul 2014 07:12:18 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aHtco6CSCRSj9SQmnsz9pyqRybAAAHPhgACXTLAA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB867FHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-08_04:2014-07-08,2014-07-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407080155 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/dWouskMLN4TQ68eAWA3NBYVYHWM Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: Re: [nvo3] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:12:32 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB867FHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The face-to-face meeting date is July 23rd and not July 30th. Sorry for the= confusion caused. Thanks, Ramki From: ramki Krishnan Sent: Monday, July 07, 2014 1:09 PM To: nvo3@ietf.org Cc: DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com); dilikris@in.ibm.com Subject: Proposed IRTF Network Functions Virtualization Research Group (NFV= RG) - first face-to-face meeting at Toronto Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB867FHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The face-to-face meeting date is July 23rd and not July 30th.= Sorry for the confusion caused.

=  

Thanks,

Ramki

 

From: ramki Krishnan
Sent: Monday, = July 07, 2014 1:09 PM
To: nvo3@ietf.org
Cc: DIEGO LOPEZ= GARCIA (diego.r.lopez@telefonica.com); dilikris@in.ibm.com
Subject:<= /b> Proposed IRTF Network Functions Virtualization Research Group (NFVRG) -= first face-to-face meeting at Toronto

 

Overview of proposed IRTF Network Functions Virtualiz= ation Research Group (NFVRG)

 

Network Function Virtualization (NFV) is a key emerging = area for network operators, hardware and software vendors, cloud service pr= oviders, and in general network practitioners and researchers. This area re= quires exploring new directions and working collaboratively on how to creat= e network services that utilize a virtualized infrastructure. Network funct= ions that are traditionally implemented in dedicated hardware appliances wi= ll need to be decomposed and executed in virtual machines running in data c= enters. One key goal of this new area is to reduce capital and operating ex= penditures for future deployments for networks and associated services. Ano= ther important goal is for the network operators to be able to offer value = added cloud services to their customers. Finally, new business models will = open for the provision of network services.

 

The technologies enabling the= virtualization of network functions are currently in an early stage of, an= d they need researchers to develop new architectures, systems, and software= , and to explore tradeoffs and possibilities for leveraging virtualized inf= rastructure to provide support for network functions. The Network Functions= Virtualization Research Group (NFVRG) will bring together researchers and = grow the community around the world in both academia and industry to explor= e this new research area through workshops, research group meetings etc. at= premier conferences such as IEEE ICC, IEEE Globecom and inviting special i= ssues in well-known journals. Some of the key topics of research include vi= rtualization of fixed and mobile network infrastructures, new network archi= tectures based on virtualized network functions, virtualization of the home= and enterprise network environments, co-existence with non-virtualized inf= rastructure and services, and application to growing areas of concern such = as Internet of Things (IoT) and next generation content distribution.<= /o:p>

 

The= NFVRG will focus on research problems associated with these topics and on = bringing a research community together that can jointly address such proble= ms, concentrating on problems that relate not just to networking but also t= o computing and storage constraints in such environments. It is also hoped = that the outcome of the research will benefit standardization efforts that = can get spawned via IRTF & IETF BoF meetings and/or provide useful inpu= t to other related standards efforts in ETSI or other standards bodies.

 

M= ore details can be found at - http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg<= /a>

 

First face-to-face Meeting in Tor= onto

 

The fi= rst face-to-face meeting of the proposed NFVRG will be held along with the = IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm in th= e Canadian (C) Room (immediately after the SFC meeting). Please let us know= if you have research topics to present during the meeting. Would really ap= preciate active discussions in the mailing list nfvrg@irtf.org.

 

Thanks,

Ram= ki on behalf of the NFVRG co-chairs

= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB867FHQ1EXCH01corp_-- From nobody Tue Jul 8 07:48:08 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9669E1B27B8; Tue, 8 Jul 2014 07:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.701 X-Spam-Level: X-Spam-Status: No, score=-12.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 iYJXTFhfQFjo; Tue, 8 Jul 2014 07:48:02 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8F81A00F6; Tue, 8 Jul 2014 07:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33809; q=dns/txt; s=iport; t=1404830882; x=1406040482; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wLLnbtwHFbNeNu8dAqZU3DU1LBL/llCAAIZiu3LDLp0=; b=DNJRx3PeHQAnf5xOBERyaC9J4Hga7Fat1wcP/Bp04Hy4tZ4v8Nb2Mc0F hY5D1WAMIPrL0SgVyUWwzigw45y5KJ36XCRGJ+bzrVDmwcMatgjL3IoHk vkwo7Y+12e4WsFF98+N49G42BjcT4bfqBNvipnjmdK+Fe0JYrUSh6N2Bw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIHAMEDvFOtJV2a/2dsb2JhbABZgkdHUlqCb6wojhGBYIc/ARl8FnWEAwEBAQQtQQsQAgEGAg4DBAEBCxYBBgUCAjAUCQgBAQQBDQUIiDoNk1ScIQiZNxePERYbBgGCczqBFgWcPpJEg0NsgUQ X-IronPort-AV: E=Sophos; i="5.01,625,1400025600"; d="scan'208,217"; a="59153805" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 08 Jul 2014 14:48:01 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s68Em0P1009340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 14:48:00 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.36]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 09:48:00 -0500 From: "Tissa Senevirathne (tsenevir)" To: Qin Wu , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9Q Date: Tue, 8 Jul 2014 14:47:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.34] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/WXgi_dYbZpC_7kT91FGC0Zt0evM Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:48:05 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77xmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUWluDQoNCk1heSBiZSBhIHBvaW50IGlzIG1pc3NlZCBoZXJlLg0KDQoNCjEuICAgICAgVGhv dWdodCBTRkMgY2FuIGdvIHVwIGFuZCBkb3duIG9uIGxheWVycywgd2hhdCBjb250cm9scyB0aGF0 IGJlaGF2aW9yID8gSXOhr250IGl0IHRoZSBTZXJ2aWNlIGhlYWRlciA/DQoNCjIuICAgICAgSXMg dGhlIE9BTSBjb21lcyBkb3duIHRvIGZhdWx0IGlzb2xhdGlvbiwgdmVyaWZpY2F0aW9uICwgbW9u aXRvcmluZyBldGMgZm9yIHRoZSBzcGVjaWZpZWQgU0ggPw0KDQpMaWtlIGRpc2N1c3NlZCBiZWZv cmUgKG1hbnkgdGltZXMpIGV4YWN0IGVuLWNhcCBpcyBsZXNzIGltcG9ydGFudCB3aGF0IGlzIGlt cG9ydGFudCBpcyB0byBoYXZlIGEgbW9kZWwgdGhhdCBkZWZpbmUgT0FNIGZyYW1ld29yayBhbmQg c2NvcGUuIENGTSB0byBteSBvcGluaW9uIGRvIGFuIGV4Y2VsbGVudCBqb2IgaW4gZGVmaW5pbmcg d2hhdCBpcyBuZWVkZWQuIEhlbmNlIHRoZSBjaG9pY2Ugb2YgYSBzaW1pbGFyIG1vZGVsIGZvciB0 aGUgWUFORyBNb2RlbC4NCg0KWW91IGhhdmUgbm90ZWQgQkZEIGFuZCBDRk0gYXJlIHNpbWlsYXIg YmVjYXVzZSB0aGV5IGhhdmUgc2ltaWxhciBzZXQgb2YgdGltZXJzLiBUaGF0IGlzIGEgd3Jvbmcg Y29tcGFyaXNvbi4gSGF2ZSBzaW1pbGFyIHNldCBvZiB0aW1lcnMgZG9lcyBub3QgbWFrZSB0d28g cHJvdG9jb2xzIHRoZSBzYW1lLiBXaGF0IG1ha2VzIHRoZW0gaXMgd2hhdCBmcmFtZXdvcmsgdGhl eSBmb2xsb3dzLiAgV2UgaGF2ZSB1c2VkIGtleSB3b3JkIENGTSBoZXJlIGxvb3NlbHkuIFRob3Vn aCB3ZSBib3Jyb3cgbG90cyBvZiBjb25jZXB0cyBmb3JtIENGTSB0aGVyZSBhcmUgdGhpbmdzIHRo YXQgbmVlZGVkIHRvIGJlIHJldmlzaXRlZC4NCg0KSSBoYXZlIHJlcXVlc3RlZCBwcmVzZW50YXRp b24gc2xvdHMgaW4gbnZvMyBhbmQgTkVUTU9EIHdvcmtpbmcgZ3JvdXBzIGFuZCB3aWxsIGJlIGdv aW5nIHRocm91Z2ggaW4gZGV0YWlscyBob3cgZWFjaCBvbmUgb2YgdGhlIHRlY2hub2xvZ2llcyBt YXAgdG8gWUFORyBtb2RlbCBwcmVzZW50ZWQgaGVyZS4NCg0KRnJvbTogUWluIFd1IFttYWlsdG86 YmlsbC53dUBodWF3ZWkuY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAwOCwgMjAxNCA1OjA3IEFN DQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7IHRpbWVAaWV0Zi5vcmcNCkNjOiBu ZXRtb2RAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IHRyaWxsQGlldGYub3JnOyBsMnZwbkBpZXRm Lm9yZzsgb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0K DQpIaSwgVGlzc2E6DQpUaGVyZSBhcmUgbWFueSBvcHRpb25zIGZvciBTRkMgT0FNLCBCRkQgZXh0 ZW5zaW9uLCBHZW5lcmljIEhlYWRlciBleHRlbnNpb24sIEdlbmVyaWMgVExWIGV4dGVuc2lvbi4N ClVubGlrZSBvdGhlciBleGlzdGluZyBPQU0gcHJvdG9jb2xzLCBtZWNoYW5pc21zIGFuZCB0b29s cywgU0ZDIG5lZWQgdG8gYWRkcmVzcyBPQU0gZm9yIHRoZSB0ZWNobm9sb2d5IHRoYXQgaXMgYWJv dmUgbGF5ZXIgMy4NClNGQyBoYXZlbqGvdCBkZXZlbG9wZWQgT0FNIHByb3RvY29sIHlldCBhdCB0 aGUgdG9wIG9mIGxheWVyIDMuDQoNCkJlZm9yZSB0aGV5IGRldmVsb3BpbmcgT0FNIHByb3RvY29s LCB0aGV5IG5lZWQgdG8gZmlndXJlIG91dCB3aGV0aGVyIHRoZXkgbmVlZCB0byBkZXZlbG9wIHRl Y2hub2xvZ3kgZGVwZW5kZW50IE9BTSBwcm90b2NvbCwNCk9yIHRlY2hub2xvZ3kgaW5kZXBlbmRl bnQgT0FNIHByb3RvY29sIHNpbmNlIFNGQyBPQU0gYW5kIE92ZXJsYXkgT0FNIHNoYXJlIGEgbG90 IG9mIHNpbWlsYXJpdGllcyhlLmcuLCBib3RoIGNhbiB1c2Ugb3ZlcmxheSB0ZWNobm9sb2d5IHRv IHN0aXRjaCBhIHNldCBvZiBvdmVybGF5IG5vZGUgb3Igc2VydmljZSBub2RlIHRvIGZvcm0gdGhl IGVuZCB0byBlbmQgcGF0aCkuIFdoeSBub3QgYnVpbGQgb25lIHByb3RvY29sIHRvIHN1cHBvcnQg Ym90aD8NCg0KVGhhdKGvcyB3aHkgd2UgYnJpbmcgdXAgdHJhbnNwb3J0IGluZGVwZW5kZW50IE9B TSBjb3ZlcmluZyB2YXJpb3VzIGhldGVyb2dlbmVvdXMgbmV0d29yayB0ZWNobm9sb2dpZXMgYW5k IHByb3Bvc2UgdG8gY29uc29saWRhdGUgT0FNIGluIGJvdGgNCk1hbmFnZW1lbnQgcGxhbmUgYW5k IGRhdGEgcGxhbmUuDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dy1vcHNhd2ct bXVsdGktbGF5ZXItb2FtLTAyDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1raW5n LW9wc2F3Zy10aW1lLW11bHRpLWxheWVyLW9hbS11c2UtY2FzZS0wMS50eHQNCg0KUmVnYXJkaW5n IGZsb3ctZW50cm9weSwgd2h5IG5vdCByZXVzZSBlbnRyb3B5IG1lY2hhbmlzbXMgaW4gdGhlIGV4 aXN0aW5nIHVuZGVybHlpbmcgdHJhbnNwb3J0LiBIb3cgaXMgZmxvdyBlbnRyb3B5IGRpZmZlcmVu dCBmcm9tIEVDTVAgY2hvaWNlIHlvdSBwcm9wb3NlZCBpbiB0aGUgZHJhZnQuDQpJZiBteSB1bmRl cnN0YW5kaW5nIGlzIGNvcnJlY3QsIElFRUUgODAyLjFhZyBvbmx5IHN1cHBvcnQgRXF1YWwgQ29z dCBUcmVlIChFQ1QpIG1lY2hhbmlzbSBpbnN0ZWFkIG9mIEVDTVAsIElFRUU4MDIuMVFicCBzdXBw b3J0IEVDTVAsDQpBcmUgeW91IHByb3Bvc2luZyB0byBjb21iaW5lIEVDVCBzdXBwb3J0ZWQgYnkg SUVFRSA4MDIuMWFnIHdpdGggRUNNUCBzdXBwb3J0ZWQgYnkgSUVFRSA4MDIuMVFicCBhbmQgdXNl IHRoZW0gdG9nZXRoZXIgYXQgdGhlIHNhbWUgdGltZSBpbiB0aGUgc2FtZSBuZXR3b3JrPw0KDQpB bHNvIEJGRCBhbmQgSUVFRSA4MDIuMWFnIENGTSBzaGFyZSBhIGxvdCBvZiBjb21tb25hbGl0eSwg ZS5nLiwgQ0NNLWludGVydmFsLCBCRkQgaW50ZXJ2YWwuIElmIHdlIGludGVncmF0ZSB0aGVtIHRv Z2V0aGVyLCB3ZSByZWFsbHkgbmVlZCB0byB0aGluayBhYm91dCBob3cgdG8gaW50ZWdyYXRlIHRo ZW0gdG9nZXRoZXIgaW4gdGhlIG1hbmFnZW1lbnQgcGxhbmUuIElzIHRoZXJlIGFueSBjb21tb24g Y29tcG9uZW50IHdlIGNhbiBkZWZpbmUgZm9yIGJvdGg/IEhvdyB3ZSBkZWZpbmUgdGhlc2UgY29t cG9uZW50IGFuZCBtYWtlIHRoZW0gbW9yZSBleHRlbnNpYmxlLg0KDQpSZWdhcmRzIQ0KLVFpbg0K t6K8/sjLOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSBbbWFpbHRvOnRzZW5ldmlyQGNp c2NvLmNvbV0NCreiy83KsbzkOiAyMDE0xOo21MIzMMjVIDA6MjANCsrVvP7IyzogUWluIFd1OyB0 aW1lQGlldGYub3JnPG1haWx0bzp0aW1lQGlldGYub3JnPg0Ks63LzTogbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYu b3JnPjsgdHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPjsgbDJ2cG5AaWV0Zi5v cmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dA aWV0Zi5vcmc+DQrW98ziOiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpIaSBRaW4NCg0KVGhl cmUgYXJlIHNldmVyYWwgd2F5IHRoaXMgaXMgYXBwbGljYWJsZSB0byBTRkMNCg0KDQoxLiAgICAg IFNGQyBpcyB1bmRlcmxheWVyIGluZGVwZW5kZW50ICwgd2hpY2ggbWVhbnMgaXQgY2FuIGhhdmUg YWxsIHNvcnRzIG9mIGVuY2FwIHR5cGVzIHVuZGVybmVhdGgsIHRoZSBtb2RlbCBwcmVzZW50ZWQg aW4gdGlzc2EtbmV0bW9kLW9hbSwgYWRkcmVzcyBleGFjdGx5IHRoYXQgaXNzdWUuIEluc3RlYWQg b2YgcmUtaW52ZW50aW5nIGFuZCByZS1pbXBsZW1lbnRpbmcgdmFyaW91cyBkaWZmZXJlbnQgT0FN IHRoZSBkcmFmdCBwcm9wb3NlIHRvIGludGVncmF0ZSB0aGVtIGF0IHRoZSBtYW5hZ2VtZW50IGxh eWVyLg0KDQoyLiAgICAgIEluIHRoaXMgZHJhZnQgd2UgZGVmaW5lIGEgZmxvdy1lbnRyb3B5IGFz IGFuIG9wYXF1ZSBlbGVtZW50IHRoYXQgZWFjaCBvZiB0aGUgdGVjaG5vbG9neSB0eXBlIGNhbiBz cGVjaWZ5IGFuZCBpbmNsdWRlLiBJZiB3ZSBsb29rIGF0IGRyYWZ0LXF1aW5uLXNmYy1uc2gtMDIu dHh0LCBpdCBkZWZpbmUgYSBibG9jayB0aGF0IHNwZWNpZmllcyBTRkMuIFNGQyB2ZXJzaW9uIG9m IFlBTkcgIGNhbiBzcGVjaWZ5IHRoaXMgYXMgcGFydCBvZiBpdHMgZmxvdyBlbnRyb3B5LiBUaGUg YmVhdXR5IGlzIHRoYXQgaXQgaXMgYWxsIHVwIHRvIHRoZSB0ZWNobm9sb2d5IHRvIHNwZWNpZnkg dGhhdCAoc2l6ZSBhbmQgc2hhcGUgaXMgdGVjaG5vbG9neSBkZXBlbmRlbnQpIGFuZCBiYXNlIG1v ZGVsIGlzIHN0aWxsIGludGFjdC4NCg0KV2l0aCB0aGUgYWJvdmUgaW4gbWluZCAsIGNhbiB5b3Ug cGxlYXNlIHJldmlldyBkcmFmdC10aXNzYS1uZXRtb2Qtb2FtIGFuZCBzZWUgaXQgaXMgZmxleGli bGUgYW5kIGV4dGVuc2libGUgZW5vdWdoIHRvIGZvciB0aGUgcHVycG9zZS4gSWYgdGhpbmdzIGFy ZSBtaXNzaW5nIHdlIGNhbiBhZGQgYW5kIGV4dGVuZC4NCg0KSSBoYXZlIHJlcXVlc3RlZCBuZXRt b2QgV0cgY2hhaXJzIGZvciBhIHByZXNlbnRhdGlvbiBzbG90IGZvciBmdXJ0aGVyIGRpc2N1c3Np b24gb2YgdGhlIGRyYWZ0Lg0KDQpGcm9tOiBRaW4gV3UgW21haWx0bzpiaWxsLnd1QGh1YXdlaS5j b21dDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDk6MjIgUE0NClRvOiBUaXNzYSBTZW5l dmlyYXRobmUgKHRzZW5ldmlyKTsgdGltZUBpZXRmLm9yZzxtYWlsdG86dGltZUBpZXRmLm9yZz4N CkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5v cmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0 Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0 Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBZQU5HIG1vZGVscyBm b3IgT0FNDQoNCkhpLCBUaXNzYToNClRoYW5rcyBmb3IgaW5pdGlhdGluZyBkaXNjdXNzaW9uIG9u IHRoaXMgdG9waWMuDQpVbmlmaWVkIE9BTSBmb3IgbXVsdGktTGF5ZXIgbmV0d29yayBpcyBhIGdv b2QgaWRlYSB0byBtZS4NCmRyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDAgd2UgcHJv cG9zZWQgaW4gb3BzYXdnIGxhaWQgb3V0IHRoZSBhbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRo ZSBwcm9ibGVtLg0KVGhlIHF1ZXN0aW9uIHRvIGRyYWZ0LXRpc3NhLW5ldG1vZC1vYW0gaXMNCkkg YW0gd29uZGVyaW5nIGhvdyB0aGlzIGdlbmVyaWMgWWFuZyBNb2RlbCBjYW4gYmUgYXBwbGllZCB0 byBTRkMgZW52aXJvbm1lbnQ/DQpIb3cgZG8geW91IHN1cHBvcnQgdGhlIGNhc2Ugd2hlcmUgdHdv IGVuZHBvaW50cyBzdXBwb3J0IGRpZmZlcmVudCBsYXllciBPQU0gb3IgZG9lc26hr3Qgc3VwcG9y dCBhbnkgT0FNIGF0IHRoYXQgbGF5ZXIuDQoNCkJUVzogSSBoYXZlIGNjoa9lZCB0aW1lIG1haWxp bmcgbGlzdCBzaW5jZSBJIGJlbGlldmUgdGhpcyBtYWlsaW5nIGxpc3QgaXMgcHVycG9zZWQgdG8g bG9vayBmb3IgZ2VuZXJpYyBhbmQgaW50ZWdyYXRlZCBPQU0gY292ZXJpbmcgdmFyaW91cyBoZXRl cm9nZW5lb3VzIG5ldHdvcmtpbmcgdGVjaG5vbG9naWVzLg0KUmVnYXJkcyENCi1RaW4NCreivP7I yzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gVGlzc2EgU2Vu ZXZpcmF0aG5lICh0c2VuZXZpcikNCreiy83KsbzkOiAyMDE0xOo21MIxMcjVIDM6MDMNCsrVvP7I yzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+OyBudm8zQGlldGYub3Jn PG1haWx0bzpudm8zQGlldGYub3JnPjsgdHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYu b3JnPjsgbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYu b3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQrW98ziOiBbbmV0bW9kXSBZQU5HIG1vZGVscyBm b3IgT0FNDQoNCkFsbA0KDQpXZSBoYXZlIHB1Ymxpc2hlZCBZQU5HIG1vZGVsIGZvciBPQU0uICMx IGRyYWZ0IGJlbG93IHBsYWNlIHRoZSBnZW5lcmljIGZyYW1ld29yayBmb3IgT0FNLCB0aGF0IGNh biBiZSBhdWdtZW50ZWQgZm9yIGRpZmZlcmVudCB0ZWNobm9sb2dpZXMuICMyIGFuZCAjMyBhcmUg YXBwbGljYXRpb24gb2YgdGhlIGNvbmNlcHQgdG8gTlZPMyBhbmQgVFJJTEwsDQoNCg0KMS4gICAg ICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW5ldG1vZC1vYW0v DQoNCjIuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1u dm8zLXlhbmctb2FtLw0KDQozLiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtdGlzc2EtdHJpbGwteWFuZy1vYW0vDQoNClBsZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlv dXIgY29tbWVudHMNCg0KVGhhbmtzDQpUaXNzYQ0KDQoNCg== --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77xmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Qin

 

May be a point is miss= ed here.

 

1.&n= bsp;     Thought SFC ca= n go up and down on layers, what controls that behavior ? Is=A1=AFnt it the= Service header ?

2.&n= bsp;     Is the OAM com= es down to fault isolation, verification , monitoring etc for the specified= SH ?

 

Like discussed before = (many times) exact en-cap is less important what is important is to have a = model that define OAM framework and scope. CFM to my opinion do an excellen= t job in defining what is needed. Hence the choice of a similar model for the YANG Model.

 

You have noted BFD and= CFM are similar because they have similar set of timers. That is a wrong c= omparison. Have similar set of timers does not make two protocols the same.= What makes them is what framework they follows.  We have used key word CFM here loosely. Though we borrow lo= ts of concepts form CFM there are things that needed to be revisited.<= /o:p>

 

I have requested prese= ntation slots in nvo3 and NETMOD working groups and will be going through i= n details how each one of the technologies map to YANG model presented here= .

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; = opsawg@ietf.org
Subject: RE: YANG models for OAM

 

Hi, T= issa:

There= are many options for SFC OAM, BFD extension, Generic Header extension, Gen= eric TLV extension.

Unlik= e other existing OAM protocols, mechanisms and tools, SFC need to address O= AM for the technology that is above layer 3.

SFC h= aven=A1=AFt developed OAM protocol yet at the top of layer 3.

=  

Befor= e they developing OAM protocol, they need to figure out whether they need t= o develop technology dependent OAM protocol,

Or te= chnology independent OAM protocol since SFC OAM and Overlay OAM share a lot= of similarities(e.g., both can use overlay technology to stitch a set of o= verlay node or service node to form the end to end path). Why not build one protocol to support both?

=  

That= =A1=AFs why we bring up transport independent OAM covering various heteroge= neous network technologies and propose to consolidate OAM in both

Manag= ement plane and data plane.

http://tools.ietf.org/html/draft-ww-opsawg-multi-laye= r-oam-02

http://tools.ietf.org/html/draft-= king-opsawg-time-multi-layer-oam-use-case-01.txt

=  

Regar= ding flow-entropy, why not reuse entropy mechanisms in the existing underly= ing transport. How is flow entropy different from ECMP choice you proposed = in the draft.

If my= understanding is correct, IEEE 802.1ag only support Equal Cost Tree (ECT) = mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are y= ou proposing to combine ECT supported by IEEE 802.1ag with ECMP supported b= y IEEE 802.1Qbp and use them together at the same time in the same network?=

=  

Also = BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., CCM-interval, BF= D interval. If we integrate them together, we really need to think about ho= w to integrate them together in the management plane. Is there any common component we can define for both? Ho= w we define these component and make them more extensible.

=  

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin

 

There are several way = this is applicable to SFC

 

1.&n= bsp;     SFC is underla= yer independent , which means it can have all sorts of encap types undernea= th, the model presented in tissa-netmod-oam, address exactly that issue. In= stead of re-inventing and re-implementing various different OAM the draft propose to integrate them at the managemen= t layer.

2.&n= bsp;     In this draft = we define a flow-entropy as an opaque element that each of the technology t= ype can specify and include. If we look at draft-quinn-sfc-nsh-02.txt, it d= efine a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entropy. Th= e beauty is that it is all up to the technology to specify that (size and s= hape is technology dependent) and base model is still intact.

 

With the above in mind= , can you please review draft-tissa-netmod-oam and see it is flexible and = extensible enough to for the purpose. If things are missing we can add and = extend.

 

I have requested netmo= d WG chairs for a presentation slot for further discussion of the draft. &n= bsp;

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, T= issa:

Thank= s for initiating discussion on this topic.

Unifi= ed OAM for multi-Layer network is a good idea to me.

draft= -ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out the an initial= description of the problem.

The q= uestion to draft-tissa-netmod-oam is

I am = wondering how this generic Yang Model can be applied to SFC environment?

How d= o you support the case where two endpoints support different layer OAM or d= oesn=A1=AFt support any OAM at that layer.

=  

BTW: = I have cc=A1=AFed time mailing list since I believe this mailing list is pu= rposed to look for generic and integrated OAM covering various heterogeneou= s networking technologies.

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: netmod [mailto:= netmod-bounces@ietf.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevi= r)
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for O= AM

 

All

 

We have published YANG model for OAM. #1 draft below= place the generic framework for OAM, that can be augmented for different t= echnologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

1.      http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/

2.      http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-o= am/

3.      http://datatracker.ietf.org/doc/draft-tissa-trill-yang= -oam/

 

Please review and share your comments

 

Thanks

Tissa

 

 

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77xmbrcdx08ciscoc_-- From nobody Tue Jul 8 07:53:12 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA5B1B2AEB; Tue, 8 Jul 2014 07:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.701 X-Spam-Level: X-Spam-Status: No, score=-12.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 NCUIGNfKrphP; Tue, 8 Jul 2014 07:52:59 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F6C1B2AF3; Tue, 8 Jul 2014 07:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35716; q=dns/txt; s=iport; t=1404831180; x=1406040780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JQ3eooMUAp6BTMN8ivm7l0C04NjTlzwDsOxXD2Q9uuU=; b=dfqfyVwvJixGOSAqRBQUQOtvc0+bQsOAN32HVuJ3bVtO1w3FjFuu3sKJ m4+tBFfLIoj24D9B/pEkChJQYLDsBi9XlwHGAfzXvSO+m1LkhY1ICy4u8 j3lzar86zybygHyOF9IbB69NYFzdXi1GsV/43dbiMJuyOBPSYgDXdtkN2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIHAGUFvFOtJA2M/2dsb2JhbABZgkdHUlqCb6wojhGBYIc/ARl8FnWEAwEBAQQtQQsQAgEGAg4DBAEBCxYBBgUCAjAUCQgBAQQBDQUIiDoNk1acIQiZNxePERYbBgGCczqBFgWcPpJEg0NsgUQ X-IronPort-AV: E=Sophos;i="5.01,625,1400025600"; d="scan'208,217";a="335402635" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 08 Jul 2014 14:52:59 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s68EqwEV022467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 14:52:58 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.36]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 09:52:57 -0500 From: "Tissa Senevirathne (tsenevir)" To: Qin Wu , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9QAACxHpA= Date: Tue, 8 Jul 2014 14:52:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.34] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/4yTUG_kBjVIHBOhYOKELBi7Gj0w Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , "opsawg@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:53:06 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 K1NGQyB3b3JraW5nIGdyb3VwLg0KDQpGcm9tOiBudm8zIFttYWlsdG86bnZvMy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNClNlbnQ6 IFR1ZXNkYXksIEp1bHkgMDgsIDIwMTQgNzo0OCBBTQ0KVG86IFFpbiBXdTsgdGltZUBpZXRmLm9y Zw0KQ2M6IGwydnBuQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IG5l dG1vZEBpZXRmLm9yZzsgdHJpbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbnZvM10gWUFORyBt b2RlbHMgZm9yIE9BTQ0KDQpIaSBRaW4NCg0KTWF5IGJlIGEgcG9pbnQgaXMgbWlzc2VkIGhlcmUu DQoNCg0KMS4gICAgICBUaG91Z2h0IFNGQyBjYW4gZ28gdXAgYW5kIGRvd24gb24gbGF5ZXJzLCB3 aGF0IGNvbnRyb2xzIHRoYXQgYmVoYXZpb3IgPyBJc6GvbnQgaXQgdGhlIFNlcnZpY2UgaGVhZGVy ID8NCg0KMi4gICAgICBJcyB0aGUgT0FNIGNvbWVzIGRvd24gdG8gZmF1bHQgaXNvbGF0aW9uLCB2 ZXJpZmljYXRpb24gLCBtb25pdG9yaW5nIGV0YyBmb3IgdGhlIHNwZWNpZmllZCBTSCA/DQoNCkxp a2UgZGlzY3Vzc2VkIGJlZm9yZSAobWFueSB0aW1lcykgZXhhY3QgZW4tY2FwIGlzIGxlc3MgaW1w b3J0YW50IHdoYXQgaXMgaW1wb3J0YW50IGlzIHRvIGhhdmUgYSBtb2RlbCB0aGF0IGRlZmluZSBP QU0gZnJhbWV3b3JrIGFuZCBzY29wZS4gQ0ZNIHRvIG15IG9waW5pb24gZG8gYW4gZXhjZWxsZW50 IGpvYiBpbiBkZWZpbmluZyB3aGF0IGlzIG5lZWRlZC4gSGVuY2UgdGhlIGNob2ljZSBvZiBhIHNp bWlsYXIgbW9kZWwgZm9yIHRoZSBZQU5HIE1vZGVsLg0KDQpZb3UgaGF2ZSBub3RlZCBCRkQgYW5k IENGTSBhcmUgc2ltaWxhciBiZWNhdXNlIHRoZXkgaGF2ZSBzaW1pbGFyIHNldCBvZiB0aW1lcnMu IFRoYXQgaXMgYSB3cm9uZyBjb21wYXJpc29uLiBIYXZlIHNpbWlsYXIgc2V0IG9mIHRpbWVycyBk b2VzIG5vdCBtYWtlIHR3byBwcm90b2NvbHMgdGhlIHNhbWUuIFdoYXQgbWFrZXMgdGhlbSBpcyB3 aGF0IGZyYW1ld29yayB0aGV5IGZvbGxvd3MuICBXZSBoYXZlIHVzZWQga2V5IHdvcmQgQ0ZNIGhl cmUgbG9vc2VseS4gVGhvdWdoIHdlIGJvcnJvdyBsb3RzIG9mIGNvbmNlcHRzIGZvcm0gQ0ZNIHRo ZXJlIGFyZSB0aGluZ3MgdGhhdCBuZWVkZWQgdG8gYmUgcmV2aXNpdGVkLg0KDQpJIGhhdmUgcmVx dWVzdGVkIHByZXNlbnRhdGlvbiBzbG90cyBpbiBudm8zIGFuZCBORVRNT0Qgd29ya2luZyBncm91 cHMgYW5kIHdpbGwgYmUgZ29pbmcgdGhyb3VnaCBpbiBkZXRhaWxzIGhvdyBlYWNoIG9uZSBvZiB0 aGUgdGVjaG5vbG9naWVzIG1hcCB0byBZQU5HIG1vZGVsIHByZXNlbnRlZCBoZXJlLg0KDQpGcm9t OiBRaW4gV3UgW21haWx0bzpiaWxsLnd1QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDA4LCAyMDE0IDU6MDcgQU0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsgdGlt ZUBpZXRmLm9yZzxtYWlsdG86dGltZUBpZXRmLm9yZz4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+ OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxt YWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpLCBUaXNzYToNClRo ZXJlIGFyZSBtYW55IG9wdGlvbnMgZm9yIFNGQyBPQU0sIEJGRCBleHRlbnNpb24sIEdlbmVyaWMg SGVhZGVyIGV4dGVuc2lvbiwgR2VuZXJpYyBUTFYgZXh0ZW5zaW9uLg0KVW5saWtlIG90aGVyIGV4 aXN0aW5nIE9BTSBwcm90b2NvbHMsIG1lY2hhbmlzbXMgYW5kIHRvb2xzLCBTRkMgbmVlZCB0byBh ZGRyZXNzIE9BTSBmb3IgdGhlIHRlY2hub2xvZ3kgdGhhdCBpcyBhYm92ZSBsYXllciAzLg0KU0ZD IGhhdmVuoa90IGRldmVsb3BlZCBPQU0gcHJvdG9jb2wgeWV0IGF0IHRoZSB0b3Agb2YgbGF5ZXIg My4NCg0KQmVmb3JlIHRoZXkgZGV2ZWxvcGluZyBPQU0gcHJvdG9jb2wsIHRoZXkgbmVlZCB0byBm aWd1cmUgb3V0IHdoZXRoZXIgdGhleSBuZWVkIHRvIGRldmVsb3AgdGVjaG5vbG9neSBkZXBlbmRl bnQgT0FNIHByb3RvY29sLA0KT3IgdGVjaG5vbG9neSBpbmRlcGVuZGVudCBPQU0gcHJvdG9jb2wg c2luY2UgU0ZDIE9BTSBhbmQgT3ZlcmxheSBPQU0gc2hhcmUgYSBsb3Qgb2Ygc2ltaWxhcml0aWVz KGUuZy4sIGJvdGggY2FuIHVzZSBvdmVybGF5IHRlY2hub2xvZ3kgdG8gc3RpdGNoIGEgc2V0IG9m IG92ZXJsYXkgbm9kZSBvciBzZXJ2aWNlIG5vZGUgdG8gZm9ybSB0aGUgZW5kIHRvIGVuZCBwYXRo KS4gV2h5IG5vdCBidWlsZCBvbmUgcHJvdG9jb2wgdG8gc3VwcG9ydCBib3RoPw0KDQpUaGF0oa9z IHdoeSB3ZSBicmluZyB1cCB0cmFuc3BvcnQgaW5kZXBlbmRlbnQgT0FNIGNvdmVyaW5nIHZhcmlv dXMgaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIHRlY2hub2xvZ2llcyBhbmQgcHJvcG9zZSB0byBjb25z b2xpZGF0ZSBPQU0gaW4gYm90aA0KTWFuYWdlbWVudCBwbGFuZSBhbmQgZGF0YSBwbGFuZS4NCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0t MDINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtpbmctb3BzYXdnLXRpbWUtbXVs dGktbGF5ZXItb2FtLXVzZS1jYXNlLTAxLnR4dA0KDQpSZWdhcmRpbmcgZmxvdy1lbnRyb3B5LCB3 aHkgbm90IHJldXNlIGVudHJvcHkgbWVjaGFuaXNtcyBpbiB0aGUgZXhpc3RpbmcgdW5kZXJseWlu ZyB0cmFuc3BvcnQuIEhvdyBpcyBmbG93IGVudHJvcHkgZGlmZmVyZW50IGZyb20gRUNNUCBjaG9p Y2UgeW91IHByb3Bvc2VkIGluIHRoZSBkcmFmdC4NCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29y cmVjdCwgSUVFRSA4MDIuMWFnIG9ubHkgc3VwcG9ydCBFcXVhbCBDb3N0IFRyZWUgKEVDVCkgbWVj aGFuaXNtIGluc3RlYWQgb2YgRUNNUCwgSUVFRTgwMi4xUWJwIHN1cHBvcnQgRUNNUCwNCkFyZSB5 b3UgcHJvcG9zaW5nIHRvIGNvbWJpbmUgRUNUIHN1cHBvcnRlZCBieSBJRUVFIDgwMi4xYWcgd2l0 aCBFQ01QIHN1cHBvcnRlZCBieSBJRUVFIDgwMi4xUWJwIGFuZCB1c2UgdGhlbSB0b2dldGhlciBh dCB0aGUgc2FtZSB0aW1lIGluIHRoZSBzYW1lIG5ldHdvcms/DQoNCkFsc28gQkZEIGFuZCBJRUVF IDgwMi4xYWcgQ0ZNIHNoYXJlIGEgbG90IG9mIGNvbW1vbmFsaXR5LCBlLmcuLCBDQ00taW50ZXJ2 YWwsIEJGRCBpbnRlcnZhbC4gSWYgd2UgaW50ZWdyYXRlIHRoZW0gdG9nZXRoZXIsIHdlIHJlYWxs eSBuZWVkIHRvIHRoaW5rIGFib3V0IGhvdyB0byBpbnRlZ3JhdGUgdGhlbSB0b2dldGhlciBpbiB0 aGUgbWFuYWdlbWVudCBwbGFuZS4gSXMgdGhlcmUgYW55IGNvbW1vbiBjb21wb25lbnQgd2UgY2Fu IGRlZmluZSBmb3IgYm90aD8gSG93IHdlIGRlZmluZSB0aGVzZSBjb21wb25lbnQgYW5kIG1ha2Ug dGhlbSBtb3JlIGV4dGVuc2libGUuDQoNClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpIFttYWlsdG86dHNlbmV2aXJAY2lzY28uY29tXQ0Kt6LLzcqx vOQ6IDIwMTTE6jbUwjMwyNUgMDoyMA0KytW8/sjLOiBRaW4gV3U7IHRpbWVAaWV0Zi5vcmc8bWFp bHRvOnRpbWVAaWV0Zi5vcmc+DQqzrcvNOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBp ZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRm Lm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCtb3zOI6 IFJFOiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpIFFpbg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCB3 YXkgdGhpcyBpcyBhcHBsaWNhYmxlIHRvIFNGQw0KDQoNCjEuICAgICAgU0ZDIGlzIHVuZGVybGF5 ZXIgaW5kZXBlbmRlbnQgLCB3aGljaCBtZWFucyBpdCBjYW4gaGF2ZSBhbGwgc29ydHMgb2YgZW5j YXAgdHlwZXMgdW5kZXJuZWF0aCwgdGhlIG1vZGVsIHByZXNlbnRlZCBpbiB0aXNzYS1uZXRtb2Qt b2FtLCBhZGRyZXNzIGV4YWN0bHkgdGhhdCBpc3N1ZS4gSW5zdGVhZCBvZiByZS1pbnZlbnRpbmcg YW5kIHJlLWltcGxlbWVudGluZyB2YXJpb3VzIGRpZmZlcmVudCBPQU0gdGhlIGRyYWZ0IHByb3Bv c2UgdG8gaW50ZWdyYXRlIHRoZW0gYXQgdGhlIG1hbmFnZW1lbnQgbGF5ZXIuDQoNCjIuICAgICAg SW4gdGhpcyBkcmFmdCB3ZSBkZWZpbmUgYSBmbG93LWVudHJvcHkgYXMgYW4gb3BhcXVlIGVsZW1l bnQgdGhhdCBlYWNoIG9mIHRoZSB0ZWNobm9sb2d5IHR5cGUgY2FuIHNwZWNpZnkgYW5kIGluY2x1 ZGUuIElmIHdlIGxvb2sgYXQgZHJhZnQtcXVpbm4tc2ZjLW5zaC0wMi50eHQsIGl0IGRlZmluZSBh IGJsb2NrIHRoYXQgc3BlY2lmaWVzIFNGQy4gU0ZDIHZlcnNpb24gb2YgWUFORyAgY2FuIHNwZWNp ZnkgdGhpcyBhcyBwYXJ0IG9mIGl0cyBmbG93IGVudHJvcHkuIFRoZSBiZWF1dHkgaXMgdGhhdCBp dCBpcyBhbGwgdXAgdG8gdGhlIHRlY2hub2xvZ3kgdG8gc3BlY2lmeSB0aGF0IChzaXplIGFuZCBz aGFwZSBpcyB0ZWNobm9sb2d5IGRlcGVuZGVudCkgYW5kIGJhc2UgbW9kZWwgaXMgc3RpbGwgaW50 YWN0Lg0KDQpXaXRoIHRoZSBhYm92ZSBpbiBtaW5kICwgY2FuIHlvdSBwbGVhc2UgcmV2aWV3IGRy YWZ0LXRpc3NhLW5ldG1vZC1vYW0gYW5kIHNlZSBpdCBpcyBmbGV4aWJsZSBhbmQgZXh0ZW5zaWJs ZSBlbm91Z2ggdG8gZm9yIHRoZSBwdXJwb3NlLiBJZiB0aGluZ3MgYXJlIG1pc3Npbmcgd2UgY2Fu IGFkZCBhbmQgZXh0ZW5kLg0KDQpJIGhhdmUgcmVxdWVzdGVkIG5ldG1vZCBXRyBjaGFpcnMgZm9y IGEgcHJlc2VudGF0aW9uIHNsb3QgZm9yIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvZiB0aGUgZHJhZnQu DQoNCkZyb206IFFpbiBXdSBbbWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbV0NClNlbnQ6IFR1ZXNk YXksIEp1bmUgMTAsIDIwMTQgOToyMiBQTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2 aXIpOyB0aW1lQGlldGYub3JnPG1haWx0bzp0aW1lQGlldGYub3JnPg0KQ2M6IG5ldG1vZEBpZXRm Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0Bp ZXRmLm9yZz47IHRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz47IGwydnBuQGll dGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3Bz YXdnQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KSGksIFRp c3NhOg0KVGhhbmtzIGZvciBpbml0aWF0aW5nIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4NClVu aWZpZWQgT0FNIGZvciBtdWx0aS1MYXllciBuZXR3b3JrIGlzIGEgZ29vZCBpZGVhIHRvIG1lLg0K ZHJhZnQtd3ctb3BzYXdnLW11bHRpLWxheWVyLW9hbS0wMCB3ZSBwcm9wb3NlZCBpbiBvcHNhd2cg bGFpZCBvdXQgdGhlIGFuIGluaXRpYWwgZGVzY3JpcHRpb24gb2YgdGhlIHByb2JsZW0uDQpUaGUg cXVlc3Rpb24gdG8gZHJhZnQtdGlzc2EtbmV0bW9kLW9hbSBpcw0KSSBhbSB3b25kZXJpbmcgaG93 IHRoaXMgZ2VuZXJpYyBZYW5nIE1vZGVsIGNhbiBiZSBhcHBsaWVkIHRvIFNGQyBlbnZpcm9ubWVu dD8NCkhvdyBkbyB5b3Ugc3VwcG9ydCB0aGUgY2FzZSB3aGVyZSB0d28gZW5kcG9pbnRzIHN1cHBv cnQgZGlmZmVyZW50IGxheWVyIE9BTSBvciBkb2VzbqGvdCBzdXBwb3J0IGFueSBPQU0gYXQgdGhh dCBsYXllci4NCg0KQlRXOiBJIGhhdmUgY2Ohr2VkIHRpbWUgbWFpbGluZyBsaXN0IHNpbmNlIEkg YmVsaWV2ZSB0aGlzIG1haWxpbmcgbGlzdCBpcyBwdXJwb3NlZCB0byBsb29rIGZvciBnZW5lcmlj IGFuZCBpbnRlZ3JhdGVkIE9BTSBjb3ZlcmluZyB2YXJpb3VzIGhldGVyb2dlbmVvdXMgbmV0d29y a2luZyB0ZWNobm9sb2dpZXMuDQpSZWdhcmRzIQ0KLVFpbg0Kt6K8/sjLOiBuZXRtb2QgW21haWx0 bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5l dmlyKQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjExyNUgMzowMw0KytW8/sjLOiBuZXRtb2RAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0 Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3 Z0BpZXRmLm9yZz4NCtb3zOI6IFtuZXRtb2RdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KQWxsDQoN CldlIGhhdmUgcHVibGlzaGVkIFlBTkcgbW9kZWwgZm9yIE9BTS4gIzEgZHJhZnQgYmVsb3cgcGxh Y2UgdGhlIGdlbmVyaWMgZnJhbWV3b3JrIGZvciBPQU0sIHRoYXQgY2FuIGJlIGF1Z21lbnRlZCBm b3IgZGlmZmVyZW50IHRlY2hub2xvZ2llcy4gIzIgYW5kICMzIGFyZSBhcHBsaWNhdGlvbiBvZiB0 aGUgY29uY2VwdCB0byBOVk8zIGFuZCBUUklMTCwNCg0KDQoxLiAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2EtbmV0bW9kLW9hbS8NCg0KMi4gICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFuZy1vYW0vDQoN CjMuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS10cmls bC15YW5nLW9hbS8NCg0KUGxlYXNlIHJldmlldyBhbmQgc2hhcmUgeW91ciBjb21tZW50cw0KDQpU aGFua3MNClRpc3NhDQoNCg0K --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+SFC working group= .

 

From: nvo3 [ma= ilto:nvo3-bounces@ietf.org] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Tuesday, July 08, 2014 7:48 AM
To: Qin Wu; time@ietf.org
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org;= trill@ietf.org
Subject: Re: [nvo3] YANG models for OAM

 

Hi Qin

 

May be a point is miss= ed here.

 

1.&n= bsp;     Thought SFC ca= n go up and down on layers, what controls that behavior ? Is=A1=AFnt it the= Service header ?

2.&n= bsp;     Is the OAM com= es down to fault isolation, verification , monitoring etc for the specified= SH ?

 

Like discussed before = (many times) exact en-cap is less important what is important is to have a = model that define OAM framework and scope. CFM to my opinion do an excellen= t job in defining what is needed. Hence the choice of a similar model for the YANG Model.

 

You have noted BFD and= CFM are similar because they have similar set of timers. That is a wrong c= omparison. Have similar set of timers does not make two protocols the same.= What makes them is what framework they follows.  We have used key word CFM here loosely. Though we borrow lo= ts of concepts form CFM there are things that needed to be revisited.<= /o:p>

 

I have requested prese= ntation slots in nvo3 and NETMOD working groups and will be going through i= n details how each one of the technologies map to YANG model presented here= .

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, T= issa:

There= are many options for SFC OAM, BFD extension, Generic Header extension, Gen= eric TLV extension.

Unlik= e other existing OAM protocols, mechanisms and tools, SFC need to address O= AM for the technology that is above layer 3.

SFC h= aven=A1=AFt developed OAM protocol yet at the top of layer 3.

=  

Befor= e they developing OAM protocol, they need to figure out whether they need t= o develop technology dependent OAM protocol,

Or te= chnology independent OAM protocol since SFC OAM and Overlay OAM share a lot= of similarities(e.g., both can use overlay technology to stitch a set of o= verlay node or service node to form the end to end path). Why not build one protocol to support both?

=  

That= =A1=AFs why we bring up transport independent OAM covering various heteroge= neous network technologies and propose to consolidate OAM in both

Manag= ement plane and data plane.

http://tools.ietf.org/html/draft-ww-opsawg-multi-laye= r-oam-02

http://tools.ietf.org/html/draft-= king-opsawg-time-multi-layer-oam-use-case-01.txt

=  

Regar= ding flow-entropy, why not reuse entropy mechanisms in the existing underly= ing transport. How is flow entropy different from ECMP choice you proposed = in the draft.

If my= understanding is correct, IEEE 802.1ag only support Equal Cost Tree (ECT) = mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are y= ou proposing to combine ECT supported by IEEE 802.1ag with ECMP supported b= y IEEE 802.1Qbp and use them together at the same time in the same network?=

=  

Also = BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., CCM-interval, BF= D interval. If we integrate them together, we really need to think about ho= w to integrate them together in the management plane. Is there any common component we can define for both? Ho= w we define these component and make them more extensible.

=  

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin

 

There are several way = this is applicable to SFC

 

1.&n= bsp;     SFC is underla= yer independent , which means it can have all sorts of encap types undernea= th, the model presented in tissa-netmod-oam, address exactly that issue. In= stead of re-inventing and re-implementing various different OAM the draft propose to integrate them at the managemen= t layer.

2.&n= bsp;     In this draft = we define a flow-entropy as an opaque element that each of the technology t= ype can specify and include. If we look at draft-quinn-sfc-nsh-02.txt, it d= efine a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entropy. Th= e beauty is that it is all up to the technology to specify that (size and s= hape is technology dependent) and base model is still intact.

 

With the above in mind= , can you please review draft-tissa-netmod-oam and see it is flexible and = extensible enough to for the purpose. If things are missing we can add and = extend.

 

I have requested netmo= d WG chairs for a presentation slot for further discussion of the draft. &n= bsp;

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, T= issa:

Thank= s for initiating discussion on this topic.

Unifi= ed OAM for multi-Layer network is a good idea to me.

draft= -ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out the an initial= description of the problem.

The q= uestion to draft-tissa-netmod-oam is

I am = wondering how this generic Yang Model can be applied to SFC environment?

How d= o you support the case where two endpoints support different layer OAM or d= oesn=A1=AFt support any OAM at that layer.

=  

BTW: = I have cc=A1=AFed time mailing list since I believe this mailing list is pu= rposed to look for generic and integrated OAM covering various heterogeneou= s networking technologies.

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: netmod [mailto:= netmod-bounces@ietf.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevi= r)
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for O= AM

 

All

 

We have published YANG model for OAM. #1 draft below= place the generic framework for OAM, that can be augmented for different t= echnologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

1.      http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/

2.      http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-o= am/

3.      http://datatracker.ietf.org/doc/draft-tissa-trill-yang= -oam/

 

Please review and share your comments

 

Thanks

Tissa

 

 

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_-- From nobody Tue Jul 8 09:28:29 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C911B2BA4; Tue, 8 Jul 2014 09:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 NwXM4sJXzhQo; Tue, 8 Jul 2014 09:28:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 331421B2BB9; Tue, 8 Jul 2014 09:28:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140708162820.3871.19940.idtracker@ietfa.amsl.com> Date: Tue, 08 Jul 2014 09:28:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/Qo3LhOb0oM4EYMTIp0n2S1QKyUc Cc: nvo3 chair , nvo3 mailing list , RFC Editor Subject: [nvo3] Document Action: 'Framework for DC Network Virtualization' to Informational RFC (draft-ietf-nvo3-framework-09.txt) X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:28:27 -0000 The IESG has approved the following document: - 'Framework for DC Network Virtualization' (draft-ietf-nvo3-framework-09.txt) as Informational RFC This document is the product of the Network Virtualization Overlays Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/ Technical Summary This document provides a framework for Network Virtualization over L3 (NVO3) and it defines a reference model along with logical components required to design a solution. Working Group Summary The document is one of the base documents chartered for the NVO3 working group. The first version of the draft was introduced at the time of the WG forming BoF for NVO3, as a way to provide network architecture context to the design of a multi-tenant data centre, for example in defining the terminology and functional blocks that are required. There has been nothing unusual or particularly controversial about the working group process for the draft. There are no IPR declarations on the draft. Document Quality I have no concerns about the quality of the document. I believe it represents WG consensus, and it has been widely reviewed and discussed on the list since formation of the NVO3 working group. The document does not specify any MIB changes or additions which would need review. Personnel The document shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com). The responsible Area Director is Alia Atlas From nobody Tue Jul 8 10:21:18 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5D61B2BD2 for ; Tue, 8 Jul 2014 10:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 ZZMhtO6BC2Er for ; Tue, 8 Jul 2014 10:21:14 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7BF1A0344 for ; Tue, 8 Jul 2014 10:21:14 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 6FDB32AA0F; Tue, 8 Jul 2014 17:21:10 +0000 (GMT) Date: Tue, 8 Jul 2014 10:21:26 -0700 From: Marc Binderberger To: Lizhong Jin , draft-liu-nvo3-ps-vxlan-perfomance@tools.ietf.org Message-ID: <20140708102126054894.57e91b45@sniff.de> In-Reply-To: <007d01cf9a54$e9400110$bbc00330$@gmail.com> References: <007d01cf9a54$e9400110$bbc00330$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/apEgWWR_U2EaJMH-F__gMoZeToA Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments of draft-liu-nvo3-ps-vxlan-perfomance-00 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:21:16 -0000 Hello Vic, Lizhong et al., > I do not quite understand the purpose of this draft. informal draft, providing numbers for VxLAN tunneling China Mobile has measured and how they have measured? Having some real numbers seems a good purpose to me. Discussing these numbers I have a few questions/comments though: I had several times a "why?" on my mind when seeing statements like: b) Memory: Memory is not sensitive from the test result. But we still think it should be listed as one VxLAN performance index. So memory doesn't seem to matter really but it still should be a performance index? Why? e) Packet-lost: Virtual network may have few packet-lost because of unstable of vCPU. Less than 2% of packet-lost is acceptable. Why is 2% acceptable? For what kind of traffic? And if the forwarding is not stable, what are these "2%"? Average? Maximum? c) Latency: When traffic is forwarded between VM to VM across two different physical server. Latency should be an index. Again: why is it relevant? Assuming it is: was it measured? VxLAN Scalable test issues I would have thought the relevant number for software VxLAN is roughly the number of VMs you have on one server, maybe with a small multiplier. Why trying to test several thousand VxLAN VNIs? That seems relevant for dedicated hardware switches that aggregate (?). The table with the CPU increase has some extreme numbers like 24.65% for server-2. I wonder how large is the error of the numbers actually? Or any idea where these extreme numbers come from? > But the performance > issues listed in section 3.1 may not true if the newly designed NIC is > applied. Some vendors are designing NIC to support VXLAN offload, and could > provide very good performance. The performance issue will not be a problem > with the emerging of newly designed NIC. Probably but this is the difference between real measurement and just a statement (as reasonable as the statement is). I hope we will see measurements for NIC-offload too one day. If today's servers cannot perform VxLAN as good as we expect then that's an important point - for now. Not sure how often Data centers renew their servers - 2 years as write-off period? So at least for this time technology/designs should address the offload onto network devices if servers lack the performance. > In the draft, you did not point out the tested traffic type. The large TCP > packet performance is a very important test point. You could refer to link > http://networkheresy.com/2012/06/08/the-overhead-of-software-tunneling/. Honestly, sending large TCP frames through a TSO NIC gives interesting numbers but is also a bit artificial - of course the numbers are good, that's what it is purpose-build for. And what about UDP, i.e. when you need GSO or something? Is this still "commodity" hardware we talk about? Regards, Marc From nobody Tue Jul 8 18:28:17 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E381A01E8; Tue, 8 Jul 2014 18:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 6U2Jd5AeAQnb; Tue, 8 Jul 2014 18:28:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EC01A01E5; Tue, 8 Jul 2014 18:28:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT65169; Wed, 09 Jul 2014 01:27:58 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 02:27:55 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 09:27:52 +0800 From: Qin Wu To: "Tissa Senevirathne (tsenevir)" , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9QABY9lIA= Date: Wed, 9 Jul 2014 01:27:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/F8O6nLT79Uz7_EScOTq4W2kWUJE Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "'sfc@ietf.org'" , "nvo3@ietf.org" , "trill@ietf.org" , "opsawg@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 01:28:08 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFRpc3NhOg0KSSBkb26hr3QgdGhpbmsgdGhlIGlkZWEgeW91IHByb3Bvc2VkIGhhdmUgYW55 IGluY29uc2lzdGVuY3kgd2l0aCB3aGF0IHdlIGFyZSBwcm9wb3NpbmcgaW4gZHJhZnQtd3ctb3Bz YXdnLW11bHRpLWxheWVyLW9hbS0wMi4gQnV0IGxvb2tzIGxpa2Ugd2UgYXJlIGRlYmF0aW5nIHNv bWV0aGluZyw6KQ0KWW91IGFuZCB1cyBhcmUgYm90aCBsb29raW5nIGZvciBPQU0gY29uc29saWRh dGlvbiBpbiB0aGUgbWFuYWdlbWVudCwgaW4gYWRkaXRpb24sIHdlIGFyZSBsb29raW5nIGZvciBP QU0gY29uc29saWRhdGlvbiBpbiB0aGUgZGF0YSBwbGFuZS4NClBsZWFzZSBzZWUgbXkgcmVwbHkg aW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzIQ0KLVFpbg0Kt6K8/sjLOiBUaXNzYSBTZW5ldmlyYXRo bmUgKHRzZW5ldmlyKSBbbWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDE0 xOo31MI4yNUgMjI6NDgNCsrVvP7IyzogUWluIFd1OyB0aW1lQGlldGYub3JnDQqzrcvNOiBuZXRt b2RAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IHRyaWxsQGlldGYub3JnOyBsMnZwbkBpZXRmLm9y Zzsgb3BzYXdnQGlldGYub3JnDQrW98ziOiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpIaSBR aW4NCg0KTWF5IGJlIGEgcG9pbnQgaXMgbWlzc2VkIGhlcmUuDQoNCg0KMS4gICAgICAgVGhvdWdo dCBTRkMgY2FuIGdvIHVwIGFuZCBkb3duIG9uIGxheWVycywgd2hhdCBjb250cm9scyB0aGF0IGJl aGF2aW9yID8gSXOhr250IGl0IHRoZSBTZXJ2aWNlIGhlYWRlciA/DQpbUWluXTogSXQgaXMgcG9z c2libGUsIGJ1dCB3aG8gY29udHJvbCB0aGF0IGJlaGF2aW9yLCBpdCBpcyB0aGUgbWFuYWdlbWVu dCBwbGFuZSwgdGhlIG1hbmFnZW1lbnQgcGxhbmUgbmVlZCB0byBpbnRlcmFjdCB3aXRoIGRpZmZl cmVudCBsYXllciBPQU0gaW4gdGhlIGRhdGEgcGxhbmUgb3INCk1hbmFnZW1lbnQgcGxhbmUgbmVl ZCB0byBpbnRlcmFjdCB3aXRoIE9BTSBwcm90b2NvbCB0aGF0IGlzIGRlZmluZWQgZm9yIFNGQyBh dCB0aGUgdG9wIG9mIGxheWVyIDMuDQoNCg0KMi4gICAgICAgSXMgdGhlIE9BTSBjb21lcyBkb3du IHRvIGZhdWx0IGlzb2xhdGlvbiwgdmVyaWZpY2F0aW9uICwgbW9uaXRvcmluZyBldGMgZm9yIHRo ZSBzcGVjaWZpZWQgU0ggPw0KW1Fpbl06IE5vdCBjbGVhciB3aGV0aGVyIFNIIGlzIHRoZSBvbmx5 IGFwcHJvYWNoLiBPQU0gaW5mb3JtYXRpb24gY2FuIGJlIHB1dCBpbnRvIEJERiBwcm90b2NvbCBv ciBHZW5lcmljIFRMViBhcyB3ZWxsLg0KDQpMaWtlIGRpc2N1c3NlZCBiZWZvcmUgKG1hbnkgdGlt ZXMpIGV4YWN0IGVuLWNhcCBpcyBsZXNzIGltcG9ydGFudCB3aGF0IGlzIGltcG9ydGFudCBpcyB0 byBoYXZlIGEgbW9kZWwgdGhhdCBkZWZpbmUgT0FNIGZyYW1ld29yayBhbmQgc2NvcGUuIENGTSB0 byBteSBvcGluaW9uIGRvIGFuIGV4Y2VsbGVudCBqb2IgaW4gZGVmaW5pbmcgd2hhdCBpcyBuZWVk ZWQuIEhlbmNlIHRoZSBjaG9pY2Ugb2YgYSBzaW1pbGFyIG1vZGVsIGZvciB0aGUgWUFORyBNb2Rl bC4NCg0KW1Fpbl06IFdlIGFyZSBvbiB0aGUgc2FtZSBwYWdlLCBidXQgaXNuoa90IG1vcmUgc3Ry YWlnaHRmb3J3YXJkIGFuZCByZWFzb25hYmxlIHRvIGRlZmluZSBHZW5lcmljIE9BTSBmcmFtZXdv cmsgc2VwYXJhdGVkIGZyb20gWWFuZyBEYXRhIG1vZGVsIGZvciBHZW5lcmljIE9BTS4NClRoYXSh r3Mgd2hhdCB3ZSBsaWtlIHRvIHByb3Bvc2UgaW4gdGhlIGRyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1s YXllci1vYW0tMDIuIERldmVsb3Bpbmcgc2VwYXJhdGUgQXJjaGl0ZWN0dXJlIGFuZCBGcmFtZXdv cmsgZnJvbSBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgT0FNIFByb2JsZW0gc3RhdGVtZW50IGRyYWZ0 Lg0KR2VuZXJpYyBPQU0gZnJhbWV3b3JrIHNob3VsZCBhbHNvIGFsbG93IG1vcmUgaW50ZXJhY3Rp b24gYmV0d2VlbiBkYXRhIHBsYW5lIGFuZCBtYW5hZ2VtZW50IHBsYW5lIGFuZCBtb3JlIGludGVy d29ya2luZyBiZXR3ZWVuIGRpZmZlcmVudCBsYXllciBPQU0gcHJvdG9jb2wuDQoNCllvdSBoYXZl IG5vdGVkIEJGRCBhbmQgQ0ZNIGFyZSBzaW1pbGFyIGJlY2F1c2UgdGhleSBoYXZlIHNpbWlsYXIg c2V0IG9mIHRpbWVycy4gVGhhdCBpcyBhIHdyb25nIGNvbXBhcmlzb24uIEhhdmUgc2ltaWxhciBz ZXQgb2YgdGltZXJzIGRvZXMgbm90IG1ha2UgdHdvIHByb3RvY29scyB0aGUgc2FtZS4NCg0KW1Fp bl06IFRoYXShr3Mgbm90IHdoYXQgd2UgYXJlIHByb3Bvc2luZywgd2UgaG9wZSBpbiB0aGUgbWFu YWdlbWVudCBwbGFuZSB0aGVyZSBpcyBzb21lIGNvbW1vbiBjb21wb25lbnRzIG9yIGVsZW1lbnRz IHRoYXQgY2FuIGJlIHVzZWQgYnkgbm90IG9ubHkgQkZELCBidXQgYWxzbyBDRk0uDQoNCldoYXQg bWFrZXMgdGhlbSBpcyB3aGF0IGZyYW1ld29yayB0aGV5IGZvbGxvd3MuICBXZSBoYXZlIHVzZWQg a2V5IHdvcmQgQ0ZNIGhlcmUgbG9vc2VseS4gVGhvdWdoIHdlIGJvcnJvdyBsb3RzIG9mIGNvbmNl cHRzIGZvcm0gQ0ZNIHRoZXJlIGFyZSB0aGluZ3MgdGhhdCBuZWVkZWQgdG8gYmUgcmV2aXNpdGVk Lg0KDQpJIGhhdmUgcmVxdWVzdGVkIHByZXNlbnRhdGlvbiBzbG90cyBpbiBudm8zIGFuZCBORVRN T0Qgd29ya2luZyBncm91cHMgYW5kIHdpbGwgYmUgZ29pbmcgdGhyb3VnaCBpbiBkZXRhaWxzIGhv dyBlYWNoIG9uZSBvZiB0aGUgdGVjaG5vbG9naWVzIG1hcCB0byBZQU5HIG1vZGVsIHByZXNlbnRl ZCBoZXJlLg0KDQpbUWluXTogVGhhdCB3b3VsZCBiZSBhIHZlcnkgZ29vZCBzdXJ2ZXksIGluIG15 IG9waW5pb24sIGJlZm9yZSBnb2luZyB0aGVyZSwgaXNuoa90IG1vcmUgbmljZSB0byBoYXZlIGEg Z2FwIGFuYWx5c2lzIGRvY3VtZW50IHRvDQphIC5JZGVudGlmeSB0ZWNobm9sb2d5IGRlcGVuZGVu dCBhbmQgaW5kZXBlbmRlbnQgY29tcG9uZW50DQpiLiAgYW5hbHl6ZSBhbmQgdW5kZXJzdGFuZCB0 aGUgZGlmZmVyZW50IG1vdGl2YXRpb25zIGFuZCBvcHBvcnR1bml0aWVzIGZvciBvcHRpbWlzYXRp b24gb2YgT0FNIGluIGRpZmZlcmVudCB0ZWNobm9sb2d5IG5ldHdvcmtzLA0KYW5kIHRoZSB0cmFk ZS1vZmZzIGJldHdlZW4gdGhvc2Ugb3B0aW1pc2F0aW9ucyBhbmQgdGhlIG92ZXJhbGwgYWR2YW50 YWdlIG9mIGEgZ2VuZXJpYyBPQU0gbWVjaGFuaXNtLg0KDQpGcm9tOiBRaW4gV3UgW21haWx0bzpi aWxsLnd1QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA4LCAyMDE0IDU6MDcgQU0N ClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsgdGltZUBpZXRmLm9yZzxtYWlsdG86 dGltZUBpZXRmLm9yZz4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxt YWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpLCBUaXNzYToNClRoZXJlIGFyZSBtYW55IG9wdGlv bnMgZm9yIFNGQyBPQU0sIEJGRCBleHRlbnNpb24sIEdlbmVyaWMgSGVhZGVyIGV4dGVuc2lvbiwg R2VuZXJpYyBUTFYgZXh0ZW5zaW9uLg0KVW5saWtlIG90aGVyIGV4aXN0aW5nIE9BTSBwcm90b2Nv bHMsIG1lY2hhbmlzbXMgYW5kIHRvb2xzLCBTRkMgbmVlZCB0byBhZGRyZXNzIE9BTSBmb3IgdGhl IHRlY2hub2xvZ3kgdGhhdCBpcyBhYm92ZSBsYXllciAzLg0KU0ZDIGhhdmVuoa90IGRldmVsb3Bl ZCBPQU0gcHJvdG9jb2wgeWV0IGF0IHRoZSB0b3Agb2YgbGF5ZXIgMy4NCg0KQmVmb3JlIHRoZXkg ZGV2ZWxvcGluZyBPQU0gcHJvdG9jb2wsIHRoZXkgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIg dGhleSBuZWVkIHRvIGRldmVsb3AgdGVjaG5vbG9neSBkZXBlbmRlbnQgT0FNIHByb3RvY29sLA0K T3IgdGVjaG5vbG9neSBpbmRlcGVuZGVudCBPQU0gcHJvdG9jb2wgc2luY2UgU0ZDIE9BTSBhbmQg T3ZlcmxheSBPQU0gc2hhcmUgYSBsb3Qgb2Ygc2ltaWxhcml0aWVzKGUuZy4sIGJvdGggY2FuIHVz ZSBvdmVybGF5IHRlY2hub2xvZ3kgdG8gc3RpdGNoIGEgc2V0IG9mIG92ZXJsYXkgbm9kZSBvciBz ZXJ2aWNlIG5vZGUgdG8gZm9ybSB0aGUgZW5kIHRvIGVuZCBwYXRoKS4gV2h5IG5vdCBidWlsZCBv bmUgcHJvdG9jb2wgdG8gc3VwcG9ydCBib3RoPw0KDQpUaGF0oa9zIHdoeSB3ZSBicmluZyB1cCB0 cmFuc3BvcnQgaW5kZXBlbmRlbnQgT0FNIGNvdmVyaW5nIHZhcmlvdXMgaGV0ZXJvZ2VuZW91cyBu ZXR3b3JrIHRlY2hub2xvZ2llcyBhbmQgcHJvcG9zZSB0byBjb25zb2xpZGF0ZSBPQU0gaW4gYm90 aA0KTWFuYWdlbWVudCBwbGFuZSBhbmQgZGF0YSBwbGFuZS4NCmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDINCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWtpbmctb3BzYXdnLXRpbWUtbXVsdGktbGF5ZXItb2FtLXVzZS1j YXNlLTAxLnR4dA0KDQpSZWdhcmRpbmcgZmxvdy1lbnRyb3B5LCB3aHkgbm90IHJldXNlIGVudHJv cHkgbWVjaGFuaXNtcyBpbiB0aGUgZXhpc3RpbmcgdW5kZXJseWluZyB0cmFuc3BvcnQuIEhvdyBp cyBmbG93IGVudHJvcHkgZGlmZmVyZW50IGZyb20gRUNNUCBjaG9pY2UgeW91IHByb3Bvc2VkIGlu IHRoZSBkcmFmdC4NCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgSUVFRSA4MDIuMWFn IG9ubHkgc3VwcG9ydCBFcXVhbCBDb3N0IFRyZWUgKEVDVCkgbWVjaGFuaXNtIGluc3RlYWQgb2Yg RUNNUCwgSUVFRTgwMi4xUWJwIHN1cHBvcnQgRUNNUCwNCkFyZSB5b3UgcHJvcG9zaW5nIHRvIGNv bWJpbmUgRUNUIHN1cHBvcnRlZCBieSBJRUVFIDgwMi4xYWcgd2l0aCBFQ01QIHN1cHBvcnRlZCBi eSBJRUVFIDgwMi4xUWJwIGFuZCB1c2UgdGhlbSB0b2dldGhlciBhdCB0aGUgc2FtZSB0aW1lIGlu IHRoZSBzYW1lIG5ldHdvcms/DQoNCkFsc28gQkZEIGFuZCBJRUVFIDgwMi4xYWcgQ0ZNIHNoYXJl IGEgbG90IG9mIGNvbW1vbmFsaXR5LCBlLmcuLCBDQ00taW50ZXJ2YWwsIEJGRCBpbnRlcnZhbC4g SWYgd2UgaW50ZWdyYXRlIHRoZW0gdG9nZXRoZXIsIHdlIHJlYWxseSBuZWVkIHRvIHRoaW5rIGFi b3V0IGhvdyB0byBpbnRlZ3JhdGUgdGhlbSB0b2dldGhlciBpbiB0aGUgbWFuYWdlbWVudCBwbGFu ZS4gSXMgdGhlcmUgYW55IGNvbW1vbiBjb21wb25lbnQgd2UgY2FuIGRlZmluZSBmb3IgYm90aD8g SG93IHdlIGRlZmluZSB0aGVzZSBjb21wb25lbnQgYW5kIG1ha2UgdGhlbSBtb3JlIGV4dGVuc2li bGUuDQoNClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2 aXIpIFttYWlsdG86dHNlbmV2aXJAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjMwyNUg MDoyMA0KytW8/sjLOiBRaW4gV3U7IHRpbWVAaWV0Zi5vcmc8bWFpbHRvOnRpbWVAaWV0Zi5vcmc+ DQqzrcvNOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0 Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxA aWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dA aWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCtb3zOI6IFJFOiBZQU5HIG1vZGVscyBm b3IgT0FNDQoNCkhpIFFpbg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCB3YXkgdGhpcyBpcyBhcHBsaWNh YmxlIHRvIFNGQw0KDQoNCjEuICAgICAgIFNGQyBpcyB1bmRlcmxheWVyIGluZGVwZW5kZW50ICwg d2hpY2ggbWVhbnMgaXQgY2FuIGhhdmUgYWxsIHNvcnRzIG9mIGVuY2FwIHR5cGVzIHVuZGVybmVh dGgsIHRoZSBtb2RlbCBwcmVzZW50ZWQgaW4gdGlzc2EtbmV0bW9kLW9hbSwgYWRkcmVzcyBleGFj dGx5IHRoYXQgaXNzdWUuIEluc3RlYWQgb2YgcmUtaW52ZW50aW5nIGFuZCByZS1pbXBsZW1lbnRp bmcgdmFyaW91cyBkaWZmZXJlbnQgT0FNIHRoZSBkcmFmdCBwcm9wb3NlIHRvIGludGVncmF0ZSB0 aGVtIGF0IHRoZSBtYW5hZ2VtZW50IGxheWVyLg0KDQoyLiAgICAgICBJbiB0aGlzIGRyYWZ0IHdl IGRlZmluZSBhIGZsb3ctZW50cm9weSBhcyBhbiBvcGFxdWUgZWxlbWVudCB0aGF0IGVhY2ggb2Yg dGhlIHRlY2hub2xvZ3kgdHlwZSBjYW4gc3BlY2lmeSBhbmQgaW5jbHVkZS4gSWYgd2UgbG9vayBh dCBkcmFmdC1xdWlubi1zZmMtbnNoLTAyLnR4dCwgaXQgZGVmaW5lIGEgYmxvY2sgdGhhdCBzcGVj aWZpZXMgU0ZDLiBTRkMgdmVyc2lvbiBvZiBZQU5HICBjYW4gc3BlY2lmeSB0aGlzIGFzIHBhcnQg b2YgaXRzIGZsb3cgZW50cm9weS4gVGhlIGJlYXV0eSBpcyB0aGF0IGl0IGlzIGFsbCB1cCB0byB0 aGUgdGVjaG5vbG9neSB0byBzcGVjaWZ5IHRoYXQgKHNpemUgYW5kIHNoYXBlIGlzIHRlY2hub2xv Z3kgZGVwZW5kZW50KSBhbmQgYmFzZSBtb2RlbCBpcyBzdGlsbCBpbnRhY3QuDQoNCldpdGggdGhl IGFib3ZlIGluIG1pbmQgLCBjYW4geW91IHBsZWFzZSByZXZpZXcgZHJhZnQtdGlzc2EtbmV0bW9k LW9hbSBhbmQgc2VlIGl0IGlzIGZsZXhpYmxlIGFuZCBleHRlbnNpYmxlIGVub3VnaCB0byBmb3Ig dGhlIHB1cnBvc2UuIElmIHRoaW5ncyBhcmUgbWlzc2luZyB3ZSBjYW4gYWRkIGFuZCBleHRlbmQu DQoNCkkgaGF2ZSByZXF1ZXN0ZWQgbmV0bW9kIFdHIGNoYWlycyBmb3IgYSBwcmVzZW50YXRpb24g c2xvdCBmb3IgZnVydGhlciBkaXNjdXNzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRnJvbTogUWluIFd1 IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KU2VudDogVHVlc2RheSwgSnVuZSAxMCwgMjAx NCA5OjIyIFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7IHRpbWVAaWV0Zi5v cmc8bWFpbHRvOnRpbWVAaWV0Zi5vcmc+DQpDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPjsgdHJpbGxA aWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPjsgbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwy dnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpIaSwgVGlzc2E6DQpUaGFua3MgZm9y IGluaXRpYXRpbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLg0KVW5pZmllZCBPQU0gZm9yIG11 bHRpLUxheWVyIG5ldHdvcmsgaXMgYSBnb29kIGlkZWEgdG8gbWUuDQpkcmFmdC13dy1vcHNhd2ct bXVsdGktbGF5ZXItb2FtLTAwIHdlIHByb3Bvc2VkIGluIG9wc2F3ZyBsYWlkIG91dCB0aGUgYW4g aW5pdGlhbCBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbS4NClRoZSBxdWVzdGlvbiB0byBkcmFm dC10aXNzYS1uZXRtb2Qtb2FtIGlzDQpJIGFtIHdvbmRlcmluZyBob3cgdGhpcyBnZW5lcmljIFlh bmcgTW9kZWwgY2FuIGJlIGFwcGxpZWQgdG8gU0ZDIGVudmlyb25tZW50Pw0KSG93IGRvIHlvdSBz dXBwb3J0IHRoZSBjYXNlIHdoZXJlIHR3byBlbmRwb2ludHMgc3VwcG9ydCBkaWZmZXJlbnQgbGF5 ZXIgT0FNIG9yIGRvZXNuoa90IHN1cHBvcnQgYW55IE9BTSBhdCB0aGF0IGxheWVyLg0KDQpCVFc6 IEkgaGF2ZSBjY6GvZWQgdGltZSBtYWlsaW5nIGxpc3Qgc2luY2UgSSBiZWxpZXZlIHRoaXMgbWFp bGluZyBsaXN0IGlzIHB1cnBvc2VkIHRvIGxvb2sgZm9yIGdlbmVyaWMgYW5kIGludGVncmF0ZWQg T0FNIGNvdmVyaW5nIHZhcmlvdXMgaGV0ZXJvZ2VuZW91cyBuZXR3b3JraW5nIHRlY2hub2xvZ2ll cy4NClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQq3osvNyrG85Dog MjAxNMTqNtTCMTHI1SAzOjAzDQrK1bz+yMs6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9k QGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz47IHRyaWxsQGll dGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz47IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZw bkBpZXRmLm9yZz47IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0K1vfM 4jogW25ldG1vZF0gWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpBbGwNCg0KV2UgaGF2ZSBwdWJsaXNo ZWQgWUFORyBtb2RlbCBmb3IgT0FNLiAjMSBkcmFmdCBiZWxvdyBwbGFjZSB0aGUgZ2VuZXJpYyBm cmFtZXdvcmsgZm9yIE9BTSwgdGhhdCBjYW4gYmUgYXVnbWVudGVkIGZvciBkaWZmZXJlbnQgdGVj aG5vbG9naWVzLiAjMiBhbmQgIzMgYXJlIGFwcGxpY2F0aW9uIG9mIHRoZSBjb25jZXB0IHRvIE5W TzMgYW5kIFRSSUxMLA0KDQoNCjEuICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdGlzc2EtbmV0bW9kLW9hbS8NCg0KMi4gICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1udm8zLXlhbmctb2FtLw0KDQozLiAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLXRyaWxsLXlhbmctb2FtLw0K DQpQbGVhc2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzDQoNClRoYW5rcw0KVGlzc2EN Cg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Tissa:

I don=A1=AFt think the idea you proposed have any inconsistency w= ith what we are proposing in draft-ww-opsawg-multi-layer-oam-02. But looks = like we are debating something,J

You and us are both looking for OAM consolidation in the manageme= nt, in addition, we are looking for OAM consolidation in the data plane.

Please see my reply inline below.

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Tissa S= enevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C28=C8=D5 22:48
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ie= tf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin<= o:p>

&n= bsp;

May be = a point is missed here.

&n= bsp;

= 1.       Thought SFC can go up and down on layers, what controls that behavior ? Is= =A1=AFnt it the Service header ?

[Qin]: It is possible, but who control that behavior, it is the m= anagement plane, the management plane need to interact with different layer= OAM in the data plane or

Management plane need to interact with OAM protocol that is defin= ed for SFC at the top of layer 3.

 

= 2.       Is the OAM comes down to fault isolation, verification , monitoring etc fo= r the specified SH ?

[Qin]: = Not clear whether SH is the only approach. OAM information can be put into = BDF protocol or Generic TLV as well.

 

Like di= scussed before (many times) exact en-cap is less important what is importan= t is to have a model that define OAM framework and scope. CFM to my opinion= do an excellent job in defining what is needed. Hence the choice of a similar model for the YANG Model.

 

[Qin]: We are on the same page, but isn=A1=AFt more straightforwa= rd and reasonable to define Generic OAM framework separated from Yang Data = model for Generic OAM.

That=A1=AFs what we like to propose in the draft-ww-opsawg-multi-= layer-oam-02. Developing separate Architecture and Framework from Transport= Independent OAM Problem statement draft.

Generic OAM framework should also allow more interaction between = data plane and management plane and more interworking between different lay= er OAM protocol.

&n= bsp;

You hav= e noted BFD and CFM are similar because they have similar set of timers. Th= at is a wrong comparison. Have similar set of timers does not make two prot= ocols the same.

 

[Qin]: That=A1=AFs not what we are proposing, we hope in the mana= gement plane there is some common components or elements that can be used b= y not only BFD, but also CFM.

 

What ma= kes them is what framework they follows.  We have used key word CFM he= re loosely. Though we borrow lots of concepts form CFM there are things tha= t needed to be revisited.

&n= bsp;

I have = requested presentation slots in nvo3 and NETMOD working groups and will be = going through in details how each one of the technologies map to YANG model= presented here.

 

[Qin]: That would be a very good survey, in my opinion, before go= ing there, isn=A1=AFt more nice to have a gap analysis document to

a .Identify technology dependent and independent component

b.  analyze and understand the different motivations and opp= ortunities for optimisation of OAM in different technology networks,

and the trade-offs between those optimisations and the overall ad= vantage of a generic OAM mechanism.

&n= bsp;

From: Qin Wu [mailto:= bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, Tissa:

There are many options for SFC OAM, BFD extension, Generic Header= extension, Generic TLV extension.

Unlike other existing OAM protocols, mechanisms and tools, SFC ne= ed to address OAM for the technology that is above layer 3.

SFC haven=A1=AFt developed OAM protocol yet at the top of layer 3= .

 

Before they developing OAM protocol, they need to figure out whet= her they need to develop technology dependent OAM protocol,

Or technology independent OAM protocol since SFC OAM and Overlay = OAM share a lot of similarities(e.g., both can use overlay technology to st= itch a set of overlay node or service node to form the end to end path). Why not build one protocol to support b= oth?

 

That=A1=AFs why we bring up transport independent OAM covering va= rious heterogeneous network technologies and propose to consolidate OAM in = both

Management plane and data plane.

http://tools.ietf.org/html/draft= -ww-opsawg-multi-layer-oam-02

http://tools= .ietf.org/html/draft-king-opsawg-time-multi-layer-oam-use-case-01.txt

 

Regarding flow-entropy, why not reuse entropy mechanisms in the e= xisting underlying transport. How is flow entropy different from ECMP choic= e you proposed in the draft.

If my understanding is correct, IEEE 802.1ag only support Equal C= ost Tree (ECT) mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are you proposing to combine ECT supported by IEEE 802.1ag with E= CMP supported by IEEE 802.1Qbp and use them together at the same time in th= e same network?

 

Also BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., C= CM-interval, BFD interval. If we integrate them together, we really need to= think about how to integrate them together in the management plane. Is there any common component we can define for b= oth? How we define these component and make them more extensible.

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Tissa S= enevirathne (tsenevir) [mailto:tsenev= ir@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin<= o:p>

&n= bsp;

There a= re several way this is applicable to SFC

&n= bsp;

= 1.       SFC is underlayer independent , which means it can have all sorts of encap= types underneath, the model presented in tissa-netmod-oam, address exactly= that issue. Instead of re-inventing and re-implementing various different OAM the draft propose to integrate t= hem at the management layer.

= 2.       In this draft we define a flow-entropy as an opaque element that each of t= he technology type can specify and include. If we look at draft-quinn-sfc-n= sh-02.txt, it define a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entrop= y. The beauty is that it is all up to the technology to specify that (size = and shape is technology dependent) and base model is still intact.

&n= bsp;

With th= e above in mind , can you please review draft-tissa-netmod-oam and see it i= s flexible and extensible enough to for the purpose. If things are missing = we can add and extend.

&n= bsp;

I have = requested netmod WG chairs for a presentation slot for further discussion o= f the draft.  

&n= bsp;

From: Qin Wu [mailto:= bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, Tissa:

Thanks for initiating discussion on this topic.=

Unified OAM for multi-Layer network is a good idea to me.

draft-ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out= the an initial description of the problem.

The question to draft-= tissa-netmod-oam is

I am wondering how this generic Yang Model can be applied to SFC = environment?

How do you support the case where two endpoints support different= layer OAM or doesn=A1=AFt support any OAM at that layer.=

 

BTW: I have cc=A1=AFed time mailing list since I believe this mai= ling list is purposed to look for generic and integrated OAM covering vario= us heterogeneous networking technologies.

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: netmod = [mailto:netmod-bounces@ietf.org<= /a>] =B4=FA= =B1=ED Tissa Senevirathne (tsenevir)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for OAM

 

All

 

We have published YANG model fo= r OAM. #1 draft below place the generic framework for OAM, that can be augm= ented for different technologies. #2 and #3 are application of the concept = to NVO3 and TRILL,

 

1. &nbs= p;     http://datatracker.ietf.org/do= c/draft-tissa-netmod-oam/

2. &nbs= p;     http://datatracker.ietf.org= /doc/draft-tissa-nvo3-yang-oam/

3. &nbs= p;     http://datatracker.ietf.or= g/doc/draft-tissa-trill-yang-oam/

 

Please review and share your co= mments

 

Thanks

Tissa

 

 

--_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_-- From nobody Tue Jul 8 19:52:53 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60871A02D5 for ; Tue, 8 Jul 2014 19:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 nodFiLZpUJTv for ; Tue, 8 Jul 2014 19:52:46 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B251A02F7 for ; Tue, 8 Jul 2014 19:52:46 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id v10so8090372pde.26 for ; Tue, 08 Jul 2014 19:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=+fGsLleoqYODk8MY+eUKep8EtVvC+V4sfelswb2M/l8=; b=rtMtH571F7x4GCGXlFrn4eeCvjfwndKTmspNI2e7aLbaY6SMRN7ljjS6Pk+ki032dv UUQ0egF8bOynMmG5qY24EknS9Q9d1T0Zt6A9P1be0+YNsqULHBqeWiai5wYkJZhNH13m LEqbKFTVqG6nsEu7L+9E+wK6B/nLhn+9DSmV/UuTExLMcu0SlX24PWwLw2jMM0DMLqig cAn50G8SodnF1UiH/dxWwvwuqn0NZUu1Bl3awpdQIY3Gxsq6V0RbyonTJoKx+DW5NPit xaAnw44maJis1c3jFzM85wI6p2XJMiVlINUyITwLdJjofaFZsGIQ7gvEYc8B4SqH67Xh HyYQ== X-Received: by 10.70.36.203 with SMTP id s11mr8782680pdj.30.1404874365838; Tue, 08 Jul 2014 19:52:45 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id s6sm26349367pdl.32.2014.07.08.19.52.41 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Jul 2014 19:52:45 -0700 (PDT) From: "Lizhong Jin" To: "'Vic Liu'" , "'Marc Binderberger'" , References: <007d01cf9a54$e9400110$bbc00330$@gmail.com> <20140708102126054894.57e91b45@sniff.de> <002e01cf9b1a$c2d46c70$487d4550$@chinamobile.com> In-Reply-To: <002e01cf9b1a$c2d46c70$487d4550$@chinamobile.com> Date: Wed, 9 Jul 2014 10:52:37 +0800 Message-ID: <011801cf9b20$dbd5e2c0$9381a840$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMAi1bCp+S49iSY/byMEK2UqGg9xgGpUxAUApe0FAWZEx/7kA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/1qBbJzfJ_C-pwyfr5SpM2yQXxKM Cc: 'Dapeng Liu' , nvo3@ietf.org, 'HuangLu' , 'gurong' , 'Haoweiguo' , =?gb2312?B?J7XLwenA8i9MaW5nbGkgRGVuZyc=?= Subject: Re: [nvo3] Comments of draft-liu-nvo3-ps-vxlan-perfomance-00 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 02:52:51 -0000 > > > But the performance > > issues listed in section 3.1 may not true if the newly designed NIC is > > applied. Some vendors are designing NIC to support VXLAN offload, and > > could provide very good performance. The performance issue will not be > > a problem with the emerging of newly designed NIC. > > Probably but this is the difference between real measurement and just a > statement (as reasonable as the statement is). I hope we will see > measurements for NIC-offload too one day. > > If today's servers cannot perform VxLAN as good as we expect then that's an > important point - for now. Not sure how often Data centers renew their > servers - 2 years as write-off period? So at least for this time > technology/designs should address the offload onto network devices if > servers lack the performance. > >>Vic: agreed. > To Lizhong: I think NIC may not matter most. The vNIC to the VSwitch maybe > matters. [Lizhong] NIC offload is will greatly improve the performance. You could refer to one test result at link: http://www.mellanox.com/blog/2013/09/connectx-3-pro-hardware-offload-engines /. The traditional NIC does not have good offloading support for tunnel packet, e.g, chechsum, TSO/LRO, Flow steering, IOV, etc. Regards Lizhong > > > > In the draft, you did not point out the tested traffic type. The large > > TCP packet performance is a very important test point. You could refer > > to link > http://networkheresy.com/2012/06/08/the-overhead-of-software- > tunneling/. > > Honestly, sending large TCP frames through a TSO NIC gives interesting > numbers but is also a bit artificial - of course the numbers are good, that's > what it is purpose-build for. And what about UDP, i.e. when you need GSO or > something? Is this still "commodity" hardware we talk about? > >>Vic: I made the traffic as a L3 traffic. > > Regards, Marc > > From nobody Mon Jul 14 12:43:38 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8643C1A00A7 for ; Mon, 14 Jul 2014 12:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 X4qBMKjJ_eRF for ; Mon, 14 Jul 2014 12:43:34 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB341A009E for ; Mon, 14 Jul 2014 12:43:33 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so2064965igb.10 for ; Mon, 14 Jul 2014 12:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dvm8TlDvzhLQFKjOsIgosNV/dZDKlG9MVVgTa/jlXf8=; b=JegKK6ptecIue9QO/WV59AqvPLByN9lfDoN61l4KipLTIeswtiwx/cKVokWoSkJarb U+Z1gHj/noAL/GRMougQiv55FjKIW3yVb832Im72Q263DSIg9QmF2KJPgmKj73+JrS41 pRmOsWk2imjmVKmcGkm/6QxsItfFnNgzwUj5mh6qfgRmEjbj6jL0m5DDsz6T1QbOH3f+ Us3s3oBbwBRlqZY+gcVxpVJ9gEVzMzemdLIRN29u75GOcqwRIOVrOMLKNKMqWZOGniV9 KPdj5/nnKThrTO3gml5PKtAbvBVBI5ooapluO2wAUvv7rTutGu3RGmieqgOa5k7Y0MH7 xQeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=dvm8TlDvzhLQFKjOsIgosNV/dZDKlG9MVVgTa/jlXf8=; b=i/571yJJVyvt/E7Lu7lf14g3Q8GeMxFG+qsul8cKJIWrcBc+63w9kPnasCoaS5e/Un 8Yx5Ma3o7+AifWmKmZeFn82UjXY32+KeFaNn6wWf6lcLPS9jtKhchejVk9sIVp4weuPR B//0l++urViGf5TVM6IJHLslw7LjC3sHH7VqEGnHvE0ipOG0ZNiHGZjiKJtOTk8vGX/M Xi6+OuLEPzSItsnHKNenjeRFK6yz8ygsYjKy20ZfuMuTH5+YnfKnl0wlrASO5qrTHCFV ll3DBOhxLXLqE3ZQfRb/gGJywMqOet4UwoFrtwH388qZxPEzKxY9NFtfUlTzOGvySvxN WM2Q== X-Gm-Message-State: ALoCoQkFT3ih9KqfMwujsY+aiIOwAJW28bY6pQTDDD3qRiNUsIopkCibWF/sti6kwdqJrE/kzVqd MIME-Version: 1.0 X-Received: by 10.50.114.197 with SMTP id ji5mr197638igb.48.1405367013484; Mon, 14 Jul 2014 12:43:33 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Mon, 14 Jul 2014 12:43:33 -0700 (PDT) Date: Mon, 14 Jul 2014 12:43:33 -0700 Message-ID: From: Tom Herbert To: "nvo3@ietf.org" , paulq@cisco.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/3kBVDn1UW4r1UOf681j8JYbjRaA Subject: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:43:35 -0000 Hi VXLAN-gpe authors, Abstract: technically this is not extending a VXLAN but defines a new protocol that looks similar to VXLAN (demonstrated by need for new UDP port assignment). Section 3.1: yet another protocol numbering scheme is defined. Why not use IP protocol numbering space. e.g. 41 for IPv6, 94 for IPv4, 97 for Ethernet. NSH would need an protocol number allocation (maybe that is the intent so these can be used at L3? ). Section 3.1: P-bit seems unnecessary to me, is more complex to process, and there is no reason to be compatible with VXLAN. Without P-bit we can always do simple indirect look-up to get protocol handler (e.g. handler = proto_handlers[protocol]), but with the P-bit we need to do an additional conditional. Also, since this now has a protocol and version in the header, the only thing fundamentally missing is a header length field. Please consider adding that. See GUE (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the justification of why this is critical. Thanks, Tom From nobody Tue Jul 15 13:41:53 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372FD1B2907 for ; Tue, 15 Jul 2014 13:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 Fcl-p-IZd2ZW for ; Tue, 15 Jul 2014 13:41:50 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3BC1B2908 for ; Tue, 15 Jul 2014 13:41:50 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 77D452AA0F; Tue, 15 Jul 2014 20:41:47 +0000 (GMT) Date: Tue, 15 Jul 2014 13:42:06 -0700 From: Marc Binderberger To: Tom Herbert , paulq@cisco.com Message-ID: <20140715134206808664.1938077e@sniff.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/ckUvbb1IaWyGc9grRkGUogxlzXM Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 20:41:52 -0000 Hello Tom, Paul et al., > Abstract: technically this is not extending a VXLAN but defines a new > protocol that looks similar to VXLAN (demonstrated by need for new UDP > port assignment). (?) ... (!) interesting, the abstract was not mentioning it although it's a relevant change IMHO when you refer to "VxLAN". Paul, few comments/questions: (1) I think the abstract should mention the requirement for a new UDP port. Especially as this suddenly showed up (it wasn't there in -02) (2) maybe a motivation why a new UDP port is needed? (3) propose to remove figure 3 and use figure 4 throughout the document as the new proposed header (4) does the whole P bit and "backward compatibility" makes sense? E.g. in 4.2 what you are doing is simply sending out a VxLAN packet according to draft-mahalingam-dutt-dcops-vxlan. Not sure there is any gain explaining how to set P, O and protocol field. And I don't see the point in 4.1, VxLAN will send to it's own port, not the new one. (5) could you provide a short motivation why you extend your flags, version field to the right side of the "I" flag when there is so much room on the left? Sure, there is LISP - is there any problem mentioning this? Elephant in the room? ;-) (6) Maybe the authors of draft-quinn-vxlan-gpe had just the same idea, independently but I have seen the OAM flag before: draft-singh-nvo3-vxlan-router-alert. If you borrowed a good idea, why not referencing? Re Tom: > Without P-bit we can always do simple indirect look-up to get protocol handler > (e.g. handler = proto_handlers[protocol]) agree. As this will go to a new UDP port one could define the packet with a protocol field, always. No confusion. One precious flag saved in a fixed header. > Also, since this now has a protocol and version in the header, the > only thing fundamentally missing is a header length field. Please > consider adding that. See GUE > (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the > justification of why this is critical. Well, ASIC/FPGA/NP people like fixed field headers, I think. I also see an advantage to have an fixed 8 byte shim with similarities between VxLAN, VxLAN-gpe and LISP (or LISP-gpe) from an implementation point of view. The hardware just needs to add 64bit from pre-programmed memory, the details how to fill the memory is done by the control plane. Parsing in hardware when receiving a packet can also be easier (with the right layout) and be shared. Regards, Marc From nobody Tue Jul 15 16:03:09 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70F71B29A5 for ; Tue, 15 Jul 2014 16:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 t_xKREET1Vvr for ; Tue, 15 Jul 2014 16:03:05 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDDC1A014F for ; Tue, 15 Jul 2014 16:03:04 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so3443550igb.9 for ; Tue, 15 Jul 2014 16:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z13DSmZUNS6VDpTmtedvqaVLTWAf77Q7BXJGLzrFDcI=; b=TOHZyjDAUJMyhL7rLb9+d9pPaAHv9drmHAdSWxf+sR63EkuJ+QEUodFFSoXyT4KDKR QZ3eAX6tyETbCOZj8u8X1oeg7SAXFRi2OTvXqrhPhxTQASVSIzCPZDUTiknCZM/B1e9b WcW919nctom772xhwzM+0QfuZJ8qNoP4jA6gSgicPme4vt7TakVVaZWWwWQjetvzfrNT 75ffEAKlG88DOZKLOyihs8gkXGDm3uVW0YcqV68UwtjkMjQTKSAQv8uzC81qHeg/p9Y0 t/jikWsRRDomEoevQN80X/0NvmBDSG6f8vrE9uJKoHOw8l5vmYwPYNGLqdLFI4+4KsUO qRTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z13DSmZUNS6VDpTmtedvqaVLTWAf77Q7BXJGLzrFDcI=; b=U2YlTOSCXNJoIxPOoKzVrCdfU+dZQud1rGNa/77NzC7CbVi4jnc/4kd6vDdfUlWOMf m1ldHsP2lnmGefYd+CQK8tkq6vLVXJRz8ItaWCTVMPqGeAWtDD5o7dAVTPNhl9XZBPDC IPRQUZNtNLy/xz6WQyrsXgVV4FPTQkQBsC0vufadq+al2wAPKZ8m+KoSaj9YuKOmNXZ3 BY1qMjCHRUbKl5o2D35Px9AlHtbi2v3ecs8Z1f8U3olw+J4/vl/QBS8jeoJPXSvCvjDo TvA+iX2KZzM6+yiY0ozf2hL2HzMY0bHDF0EXok3GkYRuyCFZvid+aX+ACi9E8997Zmh5 PFAg== X-Gm-Message-State: ALoCoQm9GzVDb6N3l0SbWLSve1EtZqKT9I/1aR9j+Wba6Pj+40R1eLV8dAe+cNUM2o6FLZyo/N2R MIME-Version: 1.0 X-Received: by 10.50.25.196 with SMTP id e4mr10684294igg.28.1405465384107; Tue, 15 Jul 2014 16:03:04 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Tue, 15 Jul 2014 16:03:04 -0700 (PDT) In-Reply-To: <20140715134206808664.1938077e@sniff.de> References: <20140715134206808664.1938077e@sniff.de> Date: Tue, 15 Jul 2014 16:03:04 -0700 Message-ID: From: Tom Herbert To: Marc Binderberger Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/UEX_1U-AlpwcRRbiyjdgKRYFNEs Cc: "nvo3@ietf.org" , paulq@cisco.com Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 23:03:08 -0000 On Tue, Jul 15, 2014 at 1:42 PM, Marc Binderberger wrote: > Hello Tom, Paul et al., > >> Abstract: technically this is not extending a VXLAN but defines a new >> protocol that looks similar to VXLAN (demonstrated by need for new UDP >> port assignment). > > (?) ... (!) interesting, the abstract was not mentioning it although it's a > relevant change IMHO when you refer to "VxLAN". > > > Paul, few comments/questions: > > (1) I think the abstract should mention the requirement for a new UDP port. > Especially as this suddenly showed up (it wasn't there in -02) > > (2) maybe a motivation why a new UDP port is needed? > > (3) propose to remove figure 3 and use figure 4 throughout the document as > the new proposed header > > (4) does the whole P bit and "backward compatibility" makes sense? E.g. in > 4.2 what you are doing is simply sending out a VxLAN packet according to > draft-mahalingam-dutt-dcops-vxlan. Not sure there is any gain explaining how > to set P, O and protocol field. And I don't see the point in 4.1, VxLAN will > send to it's own port, not the new one. > Right, once the protocol is using a different UDP port, there is no need to maintain backwards compatibility so all the deficiencies of VXLAN could be addressed in the "new" protocol (like the location of the first used flag bit, or the shift/size of the VNID). I also noticed the ambiguity if the P and O bit are simultaneously set. This ambiguity arises from the fact that the O bit is more a 1-bit type field than a flag. I would suggest donating the the O bit to the version field space to allow eight version/types. So val==0 indicates normal data packet (protocol field is present), val==1 indicates OAM packet. All the other fields (even flags) can be interpreted based on the version/type. > (5) could you provide a short motivation why you extend your flags, version > field to the right side of the "I" flag when there is so much room on the > left? Sure, there is LISP - is there any problem mentioning this? Elephant > in the room? ;-) > It's seems pretty standard to put version first in the header since the rest of the fields are interpreted based on that (e.g. IP). > (6) Maybe the authors of draft-quinn-vxlan-gpe had just the same idea, > independently but I have seen the OAM flag before: > draft-singh-nvo3-vxlan-router-alert. If you borrowed a good idea, why not > referencing? > > > > Re Tom: > >> Without P-bit we can always do simple indirect look-up to get protocol > handler >> (e.g. handler = proto_handlers[protocol]) > > agree. As this will go to a new UDP port one could define the packet with a > protocol field, always. No confusion. One precious flag saved in a fixed > header. > > >> Also, since this now has a protocol and version in the header, the >> only thing fundamentally missing is a header length field. Please >> consider adding that. See GUE >> (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the >> justification of why this is critical. > > Well, ASIC/FPGA/NP people like fixed field headers, I think. I also see an > advantage to have an fixed 8 byte shim with similarities between VxLAN, > VxLAN-gpe and LISP (or LISP-gpe) from an implementation point of view. The > hardware just needs to add 64bit from pre-programmed memory, the details how > to fill the memory is done by the control plane. Parsing in hardware when > receiving a packet can also be easier (with the right layout) and be shared. > Yes, it seems that fixed headers have become an implicit requirement in protocol design, however this conflicts with the requirement that protocols that are extensible. I think the answer is to define extensible protocols (use VLH) but assume implementations may optimized only a fix set of combinations (conceptually how routers optimize for zero length IP options, but allow packets with IP options in slow path). In practice, an encapsulation protocol like VXLAN is likely deployed in a closed network so that the encapsulation is uniform (only a small number of variants in encapsulation would be used). Introducing new fields would be a rare event, but we do need this capability and an preferably it should not require a new protocol (UDP port number) and definitely shouldn't require new HW. The ability to program HW with a small number of combinations of the protocol to parse would be awesome! :-) > > Regards, Marc From nobody Tue Jul 15 16:32:59 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727B91A0168 for ; Tue, 15 Jul 2014 16:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 nrYzqSz0F2Hk for ; Tue, 15 Jul 2014 16:32:55 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8F11A0164 for ; Tue, 15 Jul 2014 16:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2176; q=dns/txt; s=iport; t=1405467175; x=1406676775; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+MHIUriM8poT38k+JYe+nFl9nOl9tVJSa02eueYv2Kc=; b=gF9okRZ1ikcYtJQuF8jJu1EIAwGnf7IVzbe3mEcgUn9dt/1DPnufgTkQ ptJBklnWF4HurG2MKfi0EPVa0zaH7ZX/uJ2YBIUy5/y4j0s4UmhGeSMls /d7NpM1//PkJ6ctm2aYWeji34XLCyRT+oIcEi4pKKxvVWBDZdsH4ClNoZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAAm5xVOtJV2P/2dsb2JhbABZgw5SVwTBd4dCAYEOFnWEBAEBAwEOVxQFCwIBCA44MiUCBA4FiDoIDco4F48YMweDLYEWBYRuApYogUuSWoNEbIFF X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="61135088" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 15 Jul 2014 23:32:55 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6FNWsZh014282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 23:32:54 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 18:32:54 -0500 From: "Paul Quinn (paulq)" To: Tom Herbert Thread-Topic: Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPn5vlgBtfg1uBJEWg+hReV8QKvZuiHsoA Date: Tue, 15 Jul 2014 23:32:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.228] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/wbzvkwR2fyfqnz_lPtP1yz_gXUA Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 23:32:57 -0000 Hi Tom, Thanks for the questions and comments! Please see inline. On Jul 14, 2014, at 3:43 PM, Tom Herbert wrote: > Hi VXLAN-gpe authors, >=20 > Abstract: technically this is not extending a VXLAN but defines a new > protocol that looks similar to VXLAN (demonstrated by need for new UDP > port assignment). We are trying to balance re-use of the VXLAN format and the need to support= existing non-GPE hardware that might already be deployed. We looked at us= ing the same port, and the new one, and decided, at this point that a new p= ort is easier for migration but since the packet format is essentially VXLA= N to keep the VXLAN name. >=20 > Section 3.1: yet another protocol numbering scheme is defined. Why not > use IP protocol numbering space. e.g. 41 for IPv6, 94 for IPv4, 97 for > Ethernet. NSH would need an protocol number allocation (maybe that is > the intent so these can be used at L3? ). We can certainly use the IP protocol numbers for the protocols that have on= e. However, there are protocols that might be encapsulated that don=92t ha= ve an IP protocol number (not just NSH) so we still need a registry for tho= se. >=20 > Section 3.1: P-bit seems unnecessary to me, is more complex to > process, and there is no reason to be compatible with VXLAN. Without > P-bit we can always do simple indirect look-up to get protocol handler > (e.g. handler =3D proto_handlers[protocol]), but with the P-bit we need > to do an additional conditional. The P bit ensures that we have forwarding logic consistent with LISP (https= ://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/). Also, in the case if/w= hen gpe uses the same port as VXLAN, the p-bit helps with parsing on the re= ceiving end. >=20 > Also, since this now has a protocol and version in the header, the > only thing fundamentally missing is a header length field. Please > consider adding that. See GUE > (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the > justification of why this is critical. >=20 The length of the gpe header is fixed, so adding length wouldn=92t buy us m= uch?= From nobody Tue Jul 15 16:47:44 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE691B2998 for ; Tue, 15 Jul 2014 16:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Ihn1Z8yX8ts7 for ; Tue, 15 Jul 2014 16:47:39 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F35E1B2999 for ; Tue, 15 Jul 2014 16:47:39 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id v10so164525pde.6 for ; Tue, 15 Jul 2014 16:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2zAVFKQmqUA2NiflnOVPRiERfhZFQTvh+AcKKsl93N8=; b=ndOBUJpXATZ6tqKASqxUkOmqSFGql+OnpjBqqW7Z6LtxSIIE7O6N5kZuSwpireLEom +4sSl/o1b0WrheLGyVf3FZb8LlCrTWN1IL1lJYPYpYpCEY/HMF0Ydt843lWte2hllqwn HinZxoXuzr4qLYla0U0eGs7KIwZa5lhAHpx6f32zLTQElA9TuSRfxmEYGO7ZJwNWBa7a BzZyDUn2v8Dr18cyWFIBlpphBz1wwk3KkOL1CXSSRZLBPOBTgZO6d8O1PwSjloIJKBfZ Xe567vLSwtuxpjiPoIIL31mKhtZ8DdqvxkhD1GgY0RSm0xKs8nT05xk59UxKPDWQY2qS 5zOw== X-Received: by 10.70.33.228 with SMTP id u4mr3484984pdi.6.1405468058805; Tue, 15 Jul 2014 16:47:38 -0700 (PDT) Received: from [192.168.1.114] ([207.145.253.66]) by mx.google.com with ESMTPSA id ga1sm15082124pbb.82.2014.07.15.16.47.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 16:47:38 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: Date: Tue, 15 Jul 2014 16:47:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> References: To: "Paul Quinn (paulq)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/11JcUHeQC8flYADKFuRD7Lyt9jg Cc: "nvo3@ietf.org" , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 23:47:40 -0000 >>=20 >> Hi VXLAN-gpe authors, >>=20 >> Abstract: technically this is not extending a VXLAN but defines a new >> protocol that looks similar to VXLAN (demonstrated by need for new = UDP >> port assignment). >=20 > We are trying to balance re-use of the VXLAN format and the need to = support existing non-GPE hardware that might already be deployed. We = looked at using the same port, and the new one, and decided, at this = point that a new port is easier for migration but since the packet = format is essentially VXLAN to keep the VXLAN name. Paul, this design seems to be going in circles. If a new port is used, = why not make the new port for VXLAN mean layer-3 protocols follow? Or = better yet, have a demux field after the VXLAN header so you don't have = to use VXLAN header bits. Because the P-bit is using a precious bit in = the VXLAN/LISP header and the nonce field that can be used for other = things (we have history that shows a nonce in the header is a cheap form = of obscure security). If you do this then you have no compatibility problems with initial = VXLAN and LISP implementations. And, most importantly, there will be less confusion in the marketplace. Dino= From nobody Tue Jul 15 17:07:53 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200E01A01D0 for ; Tue, 15 Jul 2014 17:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 AqxV0i_Spj_7 for ; Tue, 15 Jul 2014 17:07:50 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A191A01C8 for ; Tue, 15 Jul 2014 17:07:49 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id x19so136859ier.20 for ; Tue, 15 Jul 2014 17:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ku7TtkJuU2HEBrhHGDA4ppacDc8JQCBh5uZC8ojyeXc=; b=hda/lDO7dxiAGr1THddHW9P/G26sAsIW4cwS+yYcZW+TBFe/x2vKXkDFqRUpmiGWGC laGDcs5lxSMj0rPeq9OH477CrjaM6ol9u3ce9l2zwU05C/EzTwRlAGxxR5iTkAVv40X8 X03WRye/4gTVH64+nRpxkXnnylZKH/DSvsro5w4wtHlQn0vCl6oLbrXbfE1hiGcpwwE4 fnmCq+lkQEhe86EGgXaou4msYrPe32eLhk2m1I/zeEwXIM3pYbFnrAD/p2Us3EI+foCy rXNrFuF/k57IplKnS1sevuNvx+Cx3j81zQ0DJ2KQ63PstXAYOYx7cB1NhnHZ+rY78II9 nzQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ku7TtkJuU2HEBrhHGDA4ppacDc8JQCBh5uZC8ojyeXc=; b=T54h8TLRGJaPa5sWuhHB7c9cqpRlG0+VuliCcS1x/Jcf/4myu/4Lzupysnt4VRKx/0 aYhQAb4HQF17dwBDV0WCInqLi9i77fkAIKGnyw1RBZiA4tWA+beNl1OhNnbgisRmlnOF AKHneoTp+B+HUEA0t7a1FbOiyZpMn3w3mdMlJGah3OD1DQENYdYFbU/8zlChH+vySWzy v9IjLENyZVyJpm8fMeK8B/sHoYAZDzSBtAcfV9BUoxWIuVawlUKb4S48kTUNtoX0CWqH EzapxURJqoqa92Fly5C7u19V+at0tQsM6O0IM7SG+22vOYba7sQCeswyZUg/+EPeJfSW H97g== X-Gm-Message-State: ALoCoQk/ebjhNC2sFFfhgdBG6GsqE25BdZVFhPhsOqiD2xenOddo+3zWCqNPZVKT3ITC04R9Oobm MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr10744825igt.29.1405469269089; Tue, 15 Jul 2014 17:07:49 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Tue, 15 Jul 2014 17:07:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Jul 2014 17:07:48 -0700 Message-ID: From: Tom Herbert To: "Paul Quinn (paulq)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/cEhy87ip9TcqAitSCAgAcCGZl1k Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:07:52 -0000 On Tue, Jul 15, 2014 at 4:32 PM, Paul Quinn (paulq) wrote= : > Hi Tom, > > Thanks for the questions and comments! Please see inline. > > On Jul 14, 2014, at 3:43 PM, Tom Herbert wrote: > >> Hi VXLAN-gpe authors, >> >> Abstract: technically this is not extending a VXLAN but defines a new >> protocol that looks similar to VXLAN (demonstrated by need for new UDP >> port assignment). > > We are trying to balance re-use of the VXLAN format and the need to suppo= rt existing non-GPE hardware that might already be deployed. We looked at = using the same port, and the new one, and decided, at this point that a new= port is easier for migration but since the packet format is essentially VX= LAN to keep the VXLAN name. > > >> >> Section 3.1: yet another protocol numbering scheme is defined. Why not >> use IP protocol numbering space. e.g. 41 for IPv6, 94 for IPv4, 97 for >> Ethernet. NSH would need an protocol number allocation (maybe that is >> the intent so these can be used at L3? ). > > We can certainly use the IP protocol numbers for the protocols that have = one. However, there are protocols that might be encapsulated that don=E2= =80=99t have an IP protocol number (not just NSH) so we still need a regist= ry for those. > NSH looks an awful lot like an IP extension header to me, have you considered requesting a protocol number for this? You can always use proto=3D47 (GRE) as an secondary encapsulation header to encapsulate the full ETHER_TYPE range. This technique is described in GUE draft (cost is 4 bytes and a little bit of processing for these other protocols not represented by an IP protocol number). > >> >> Section 3.1: P-bit seems unnecessary to me, is more complex to >> process, and there is no reason to be compatible with VXLAN. Without >> P-bit we can always do simple indirect look-up to get protocol handler >> (e.g. handler =3D proto_handlers[protocol]), but with the P-bit we need >> to do an additional conditional. > > The P bit ensures that we have forwarding logic consistent with LISP (htt= ps://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/). Also, in the case if= /when gpe uses the same port as VXLAN, the p-bit helps with parsing on the = receiving end. > I think there's more logic in being consistent with Ethernet, IP, GRE protocol standards where the next protocol field is always valid as an invariant. > > >> >> Also, since this now has a protocol and version in the header, the >> only thing fundamentally missing is a header length field. Please >> consider adding that. See GUE >> (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the >> justification of why this is critical. >> > > The length of the gpe header is fixed, so adding length wouldn=E2=80=99t = buy us much? Fixed length gpe (or in VXLAN for that matter) implies no protocol eXtensibility :-). Thanks, Tom From nobody Tue Jul 15 22:47:40 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B39F1B2A75 for ; Tue, 15 Jul 2014 22:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 qVtk7wBVwBwt for ; Tue, 15 Jul 2014 22:47:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CF21A02DC for ; Tue, 15 Jul 2014 22:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6245; q=dns/txt; s=iport; t=1405489656; x=1406699256; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1qgATiJO11yGrk4WjeNzN1No8BoP3lDij0IGBVsiiTo=; b=Me02JvFTGWzalHRd1ggirshso7X3dHs2CRmQqGHbGiqUisRiKXBKu5qm 7WH8pYHoRl/pqwm+t5LFNeIiwjQ1saj74E6Guurs9pHei+DEu4KuIRBR3 pqVWZUBACZ5FBgEYfNNULTUPq1dWUxM3RIiCmtzgTRUiKj/x05xUvfHY7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAG0RxlOtJA2D/2dsb2JhbABZgw5SV8IGCodCAYEUFnWEBAEBBAEBATU0AggCEQsYCRYPCQMCAQIBFTATBgIBAYg+DcoTF49ShEMFimGQN4FLhUiNEoNkHS8 X-IronPort-AV: E=Sophos;i="5.01,669,1400025600"; d="scan'208";a="340410197" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2014 05:47:35 +0000 Received: from [10.21.73.205] ([10.21.73.205]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6G5lYFp020609 for ; Wed, 16 Jul 2014 05:47:35 GMT Message-ID: <53C611F6.9010805@cisco.com> Date: Tue, 15 Jul 2014 22:47:34 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: nvo3@ietf.org References: <20140715134206808664.1938077e@sniff.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/tRM5-OEU51dYiV7ra8YIiMCd5Yc Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 05:47:38 -0000 Tom, one of the design goals of GPE is to be cost effective when implemented together with VXLAN and LISP. We do know that those are the two most deployed protocols out there, and will be out there for quite some time while any other network virtualization protocol gets deployed. I believe that sharing the parsing logic across the new and legacy protocols, is a significant reduction in complexity that eventually will help adoption of GPE. At the same time we want to facilitate convergence to a protocol that can be extended with new features. Multiprotocol support and explicit service tagging being the two most notable. GPE with the next protocol and version fields provides a trade off between those two contrasting requirements. When you consider the flexibility of GPE, you shoud look at the combination of gpe with a shim header a-la nsh, that I believe provides the flexibility needed to carry additional metadata. It's also my understanding that gpe+nsh would satisfy the requirements for NIC processing that you describe in the GUE draft. Finally the P bit. It simply leaves open the opportunity to deploy GPE on the same port of VXLAN (or LISP). I believe that in some deployments this may become an advantage, that is worth the use of one bit (especially considering that with the compact next protocol field we make available further bits in the GPE header to future versions). Thanks, Fabio On 7/15/14, 4:03 PM, Tom Herbert wrote: > On Tue, Jul 15, 2014 at 1:42 PM, Marc Binderberger wrote: >> Hello Tom, Paul et al., >> >>> Abstract: technically this is not extending a VXLAN but defines a new >>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>> port assignment). >> (?) ... (!) interesting, the abstract was not mentioning it although it's a >> relevant change IMHO when you refer to "VxLAN". >> >> >> Paul, few comments/questions: >> >> (1) I think the abstract should mention the requirement for a new UDP port. >> Especially as this suddenly showed up (it wasn't there in -02) >> >> (2) maybe a motivation why a new UDP port is needed? >> >> (3) propose to remove figure 3 and use figure 4 throughout the document as >> the new proposed header >> >> (4) does the whole P bit and "backward compatibility" makes sense? E.g. in >> 4.2 what you are doing is simply sending out a VxLAN packet according to >> draft-mahalingam-dutt-dcops-vxlan. Not sure there is any gain explaining how >> to set P, O and protocol field. And I don't see the point in 4.1, VxLAN will >> send to it's own port, not the new one. >> > Right, once the protocol is using a different UDP port, there is no > need to maintain backwards compatibility so all the deficiencies of > VXLAN could be addressed in the "new" protocol (like the location of > the first used flag bit, or the shift/size of the VNID). > > I also noticed the ambiguity if the P and O bit are simultaneously > set. This ambiguity arises from the fact that the O bit is more a > 1-bit type field than a flag. I would suggest donating the the O bit > to the version field space to allow eight version/types. So val==0 > indicates normal data packet (protocol field is present), val==1 > indicates OAM packet. All the other fields (even flags) can be > interpreted based on the version/type. > >> (5) could you provide a short motivation why you extend your flags, version >> field to the right side of the "I" flag when there is so much room on the >> left? Sure, there is LISP - is there any problem mentioning this? Elephant >> in the room? ;-) >> > It's seems pretty standard to put version first in the header since > the rest of the fields are interpreted based on that (e.g. IP). > >> (6) Maybe the authors of draft-quinn-vxlan-gpe had just the same idea, >> independently but I have seen the OAM flag before: >> draft-singh-nvo3-vxlan-router-alert. If you borrowed a good idea, why not >> referencing? >> >> >> >> Re Tom: >> >>> Without P-bit we can always do simple indirect look-up to get protocol >> handler >>> (e.g. handler = proto_handlers[protocol]) >> agree. As this will go to a new UDP port one could define the packet with a >> protocol field, always. No confusion. One precious flag saved in a fixed >> header. >> >> >>> Also, since this now has a protocol and version in the header, the >>> only thing fundamentally missing is a header length field. Please >>> consider adding that. See GUE >>> (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the >>> justification of why this is critical. >> Well, ASIC/FPGA/NP people like fixed field headers, I think. I also see an >> advantage to have an fixed 8 byte shim with similarities between VxLAN, >> VxLAN-gpe and LISP (or LISP-gpe) from an implementation point of view. The >> hardware just needs to add 64bit from pre-programmed memory, the details how >> to fill the memory is done by the control plane. Parsing in hardware when >> receiving a packet can also be easier (with the right layout) and be shared. >> > Yes, it seems that fixed headers have become an implicit requirement > in protocol design, however this conflicts with the requirement that > protocols that are extensible. I think the answer is to define > extensible protocols (use VLH) but assume implementations may > optimized only a fix set of combinations (conceptually how routers > optimize for zero length IP options, but allow packets with IP options > in slow path). In practice, an encapsulation protocol like VXLAN is > likely deployed in a closed network so that the encapsulation is > uniform (only a small number of variants in encapsulation would be > used). Introducing new fields would be a rare event, but we do need > this capability and an preferably it should not require a new protocol > (UDP port number) and definitely shouldn't require new HW. The ability > to program HW with a small number of combinations of the protocol to > parse would be awesome! :-) > >> Regards, Marc > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Tue Jul 15 22:51:34 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657F41A02DC for ; Tue, 15 Jul 2014 22:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 8-qHsDGfa8R7 for ; Tue, 15 Jul 2014 22:51:32 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68BF1B2A75 for ; Tue, 15 Jul 2014 22:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2453; q=dns/txt; s=iport; t=1405489891; x=1406699491; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=f1fHdBdJ/rS2/oOBZ4BMa9FVBWNEpREZJXMCpm1C7g8=; b=VoLo9PLmEde9u9U/SS/VIWvMNvTDUpSMy3KoQSgmQ4dG6NX82i1OXd4p +ZgNcwdLthSZEPI+K3urEqtPVs2W8zCoF7yQeBcRJhNh24wcfhYFU/1Or xwYMKXmNDEep7ScSjbI5390K5SIEKcJwBJEyHkI1I3x15t2VZMaLMXTAK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FABwSxlOtJA2N/2dsb2JhbABZgw5SV8IGCodCAYEUFnWEBAEBBAEBAQsqLQkKEQsYCRYPCQMCAQIBFTATBgIBAYg+DcoUF49SFoQtBYphkDeBS4VIjRKDZB0v X-IronPort-AV: E=Sophos;i="5.01,670,1400025600"; d="scan'208";a="61203542" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 16 Jul 2014 05:51:31 +0000 Received: from [10.21.73.205] ([10.21.73.205]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6G5pTHr003103 for ; Wed, 16 Jul 2014 05:51:30 GMT Message-ID: <53C612E1.1050501@cisco.com> Date: Tue, 15 Jul 2014 22:51:29 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: nvo3@ietf.org References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> In-Reply-To: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/CgV8_z7FL7w2wCxPyZW1gLSStWA Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 05:51:33 -0000 Dino, I believe that using a format that can share as much as possible with the two protocols deployed today will give a better chance to GPE to be implemented, as vendors may want a cost effective way to migrate to the new protocol while preserving compatibility with legacy implementations. The fact that GPE provides a way to be extended, either with a shim a-la NSH or making availabe more bits in the header for future features, I think opens up to the addition of new features (explicit service tagging, as an example) in a more organic way than trying to use the few bits left in VXLAN or LISP. Unfortunately, in the LISP case, this comes to the expense of some features that are in the current specification, but I believe those same features can be mapped on a GPE+shim header, so a new implementation would be able to provide the equivalent of those features (e.g. nonce). It's hard to find the right balance between backward compatibility and evolution of the encapsulation, but I believe GPE gets to a decent compromise. Thanks, Fabio On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>> Hi VXLAN-gpe authors, >>> >>> Abstract: technically this is not extending a VXLAN but defines a new >>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>> port assignment). >> We are trying to balance re-use of the VXLAN format and the need to support existing non-GPE hardware that might already be deployed. We looked at using the same port, and the new one, and decided, at this point that a new port is easier for migration but since the packet format is essentially VXLAN to keep the VXLAN name. > Paul, this design seems to be going in circles. If a new port is used, why not make the new port for VXLAN mean layer-3 protocols follow? Or better yet, have a demux field after the VXLAN header so you don't have to use VXLAN header bits. Because the P-bit is using a precious bit in the VXLAN/LISP header and the nonce field that can be used for other things (we have history that shows a nonce in the header is a cheap form of obscure security). > > If you do this then you have no compatibility problems with initial VXLAN and LISP implementations. > > And, most importantly, there will be less confusion in the marketplace. > > Dino > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Tue Jul 15 22:58:15 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E981B2A75 for ; Tue, 15 Jul 2014 22:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1-QNwr4lmkUa for ; Tue, 15 Jul 2014 22:58:13 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37321B2A9D for ; Tue, 15 Jul 2014 22:58:12 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s6G5ujd5000752; Tue, 15 Jul 2014 22:58:12 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1n336k38bj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 22:58:11 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Jul 2014 22:58:10 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::f5db:81ae:2a14:f915%12]) with mapi; Tue, 15 Jul 2014 22:58:10 -0700 From: ramki Krishnan To: "'nvo3@ietf.org'" Date: Tue, 15 Jul 2014 22:58:10 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+glo0SWV5Tpf8ORV2qBe787uS76gAJFXgA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9612HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-16_03:2014-07-15,2014-07-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407160076 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/z7MLhvrVJ4VmzMQLfgnFNnUEWV0 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: [nvo3] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 05:58:14 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9612HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find more information on NFVRG including charter at - http://trac.to= ols.ietf.org/group/irtf/trac/wiki/nfvrg Please find meeting location and agenda at - http://trac.tools.ietf.org/gro= up/irtf/trac/wiki/nfvrg-ietf-90 Thanks, Ramki on behalf of the co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9612HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find more= information on NFVRG including charter at - http://trac.tools.ietf.org/group/irtf/t= rac/wiki/nfvrg

 

=

Please find meeting location and agenda at - http://t= rac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90

 

Thanks,

Ramki on behalf of the co-chairs

=
= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9612HQ1EXCH01corp_-- From nobody Tue Jul 15 23:22:04 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1581A002C for ; Tue, 15 Jul 2014 23:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 g3E9NypdmbT5 for ; Tue, 15 Jul 2014 23:21:58 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 569BE1B2AB2 for ; Tue, 15 Jul 2014 23:21:57 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 952EF2AA0F; Wed, 16 Jul 2014 06:21:54 +0000 (GMT) Date: Tue, 15 Jul 2014 23:22:14 -0700 From: Marc Binderberger To: Tom Herbert Message-ID: <20140715232214444019.e52a0d56@sniff.de> In-Reply-To: References: <20140715134206808664.1938077e@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/wbWVfi_PA6JnZ81t2EWai2yjyeo Cc: "nvo3@ietf.org" , paulq@cisco.com Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 06:22:02 -0000 Hello Tom, > I also noticed the ambiguity if the P and O bit are simultaneously > set. This ambiguity arises from the fact that the O bit is more a > 1-bit type field than a flag. well, you may have a different OAM behaviour per protocol. It's hard to say as the details of OAM are out of scope for the document, I guess. Even a simple "punt to control plane" is still punting to different receivers depending on layer-2, IPv4, IPv6 etc. > Yes, it seems that fixed headers have become an implicit requirement > in protocol design, however this conflicts with the requirement that > protocols that are extensible. well, that's where the version field comes into play. > The ability > to program HW with a small number of combinations of the protocol to > parse would be awesome! :-) Agree. Assuming it's really a small number :-) Regards, Marc On Tue, 15 Jul 2014 16:03:04 -0700, Tom Herbert wrote: > On Tue, Jul 15, 2014 at 1:42 PM, Marc Binderberger wrote: >> Hello Tom, Paul et al., >> >>> Abstract: technically this is not extending a VXLAN but defines a new >>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>> port assignment). >> >> (?) ... (!) interesting, the abstract was not mentioning it although it's a >> relevant change IMHO when you refer to "VxLAN". >> >> >> Paul, few comments/questions: >> >> (1) I think the abstract should mention the requirement for a new UDP port. >> Especially as this suddenly showed up (it wasn't there in -02) >> >> (2) maybe a motivation why a new UDP port is needed? >> >> (3) propose to remove figure 3 and use figure 4 throughout the document as >> the new proposed header >> >> (4) does the whole P bit and "backward compatibility" makes sense? E.g. in >> 4.2 what you are doing is simply sending out a VxLAN packet according to >> draft-mahalingam-dutt-dcops-vxlan. Not sure there is any gain explaining >> how >> to set P, O and protocol field. And I don't see the point in 4.1, VxLAN >> will >> send to it's own port, not the new one. >> > Right, once the protocol is using a different UDP port, there is no > need to maintain backwards compatibility so all the deficiencies of > VXLAN could be addressed in the "new" protocol (like the location of > the first used flag bit, or the shift/size of the VNID). > > I also noticed the ambiguity if the P and O bit are simultaneously > set. This ambiguity arises from the fact that the O bit is more a > 1-bit type field than a flag. I would suggest donating the the O bit > to the version field space to allow eight version/types. So val==0 > indicates normal data packet (protocol field is present), val==1 > indicates OAM packet. All the other fields (even flags) can be > interpreted based on the version/type. > >> (5) could you provide a short motivation why you extend your flags, version >> field to the right side of the "I" flag when there is so much room on the >> left? Sure, there is LISP - is there any problem mentioning this? Elephant >> in the room? ;-) >> > It's seems pretty standard to put version first in the header since > the rest of the fields are interpreted based on that (e.g. IP). > >> (6) Maybe the authors of draft-quinn-vxlan-gpe had just the same idea, >> independently but I have seen the OAM flag before: >> draft-singh-nvo3-vxlan-router-alert. If you borrowed a good idea, why not >> referencing? >> >> >> >> Re Tom: >> >>> Without P-bit we can always do simple indirect look-up to get protocol >> handler >>> (e.g. handler = proto_handlers[protocol]) >> >> agree. As this will go to a new UDP port one could define the packet with a >> protocol field, always. No confusion. One precious flag saved in a fixed >> header. >> >> >>> Also, since this now has a protocol and version in the header, the >>> only thing fundamentally missing is a header length field. Please >>> consider adding that. See GUE >>> (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the >>> justification of why this is critical. >> >> Well, ASIC/FPGA/NP people like fixed field headers, I think. I also see an >> advantage to have an fixed 8 byte shim with similarities between VxLAN, >> VxLAN-gpe and LISP (or LISP-gpe) from an implementation point of view. The >> hardware just needs to add 64bit from pre-programmed memory, the details >> how >> to fill the memory is done by the control plane. Parsing in hardware when >> receiving a packet can also be easier (with the right layout) and be >> shared. >> > Yes, it seems that fixed headers have become an implicit requirement > in protocol design, however this conflicts with the requirement that > protocols that are extensible. I think the answer is to define > extensible protocols (use VLH) but assume implementations may > optimized only a fix set of combinations (conceptually how routers > optimize for zero length IP options, but allow packets with IP options > in slow path). In practice, an encapsulation protocol like VXLAN is > likely deployed in a closed network so that the encapsulation is > uniform (only a small number of variants in encapsulation would be > used). Introducing new fields would be a rare event, but we do need > this capability and an preferably it should not require a new protocol > (UDP port number) and definitely shouldn't require new HW. The ability > to program HW with a small number of combinations of the protocol to > parse would be awesome! :-) > >> >> Regards, Marc > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > From nobody Wed Jul 16 00:07:30 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DA81B2A9D for ; Wed, 16 Jul 2014 00:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 dKDdmRRNEixJ for ; Wed, 16 Jul 2014 00:07:25 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C681B29D0 for ; Wed, 16 Jul 2014 00:07:24 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so746956pde.9 for ; Wed, 16 Jul 2014 00:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=XrEMb09oYQMnYKb8F8BrxFDpTGukRXzFdNxV8hFDEcE=; b=mZX4cYWk4jrorvrnVUoJ8FpBGRoKZc2DYxEsNHhkVhjKNLHVlLpQX1EparlZ9QkiMn CUCYg49Kzz2rtX2x0wdTv+XxlfC3bn20YhXuRuoJVHzixmnKJRtEe17XX0P0viUUDBAU ymaAkWHWX4NHWx5JJGWfLFuZyQSoqKroOoqy0m5Kt084eotIeCJgzgnbvVPm6j+g1ZJh stkHF1sA0A4+meADnVaItafJwcQyfDmuJ6eD6lJb1kKrJEYrzb3N+vW0aA98ZGSOfi7C XR5uzbEL0WCCMaD+cSHmeB4iagvbIH2BwGDc/W4K6CjqQhLp2VLrUgj2HZxR9z6F8IRM llQg== X-Received: by 10.70.95.5 with SMTP id dg5mr22034257pdb.93.1405494444274; Wed, 16 Jul 2014 00:07:24 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id qf10sm16007423pbc.23.2014.07.16.00.07.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 00:07:23 -0700 (PDT) From: Sam Aldrin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jul 2014 00:07:21 -0700 Message-Id: To: nvo3@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/p25BKdycGsP-0OTG7mJS2xuhVM0 Cc: Benson Schliesser , "Bocci, Matthew \(Matthew\)" Subject: [nvo3] Draft Agenda of IETF90 WG session X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 07:07:27 -0000 Hi, Draft Agenda is now posted. () All presenters, please send in your presentations no later than 21st = July i.e. Monday EOB. Please unicast it to me and cc WG chairs. If there are any mistakes or corrections needed to the Agenda, please = let us know. Final agenda and the order may change as we get closer to the meeting. cheers -sam= From nobody Wed Jul 16 07:39:27 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E521B28AA for ; Wed, 16 Jul 2014 07:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 N_CJEeUBDDWz for ; Wed, 16 Jul 2014 07:39:21 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54CF1B287B for ; Wed, 16 Jul 2014 07:39:21 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id h15so4194496igd.17 for ; Wed, 16 Jul 2014 07:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m6WbIKoh93nfBurjykNgW/H+OausuR5YlSNjzGZSTGA=; b=mY0q7uFjohpOsxSmMEROV0Ucx8UY+CSFJyIRsYgRRqeCfR0QOShyFEChQy2cZ3CqvM UOwOlrjV3isJ/pXvn98BHsE7yQQ4JHHY48op8uRm2OV86bosu50DNke9AwK2/rPKVKIg 9aVmKXauGVb515JzAj6JLUAO8o/iaa4S54P9XANiSfKufDTrsOUiG4I+jH7SxWxUzJ+K 90EXkpFr3ntj1+WTTSVYq1vL5d39/jg2C9YP+QgyBbPuYA2liWFQiVxMKbyPPazh4oTn i6PEd7K31A16Q5+Zjt0TWuZqAcgs3kMJRv7BW0uVJoO0K27de45Dy2mSJicYG0cykMK+ YohQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m6WbIKoh93nfBurjykNgW/H+OausuR5YlSNjzGZSTGA=; b=VThczGInvDSh0004PkLfTqL2haVlVFM1R7SygiTMEnVDrtP77TVrEZMgpFyoyhjISw XAXJBhoyOREzFujz4wK2xZU8TDSe0CGDX4Iu0LD3/3zlIy1bNYZiArGm//TL11aENGzp hSLTW8mX/2ylAAfaaO+zGS333wDLYKbdTUZFyQhZ1nmx0DvDysmcwCwj6ldIqCCgGDsB u7B8JZctTHNbtznZ3XTb8NmNnNQ7q6+7kV1OXfMaPTrcs8xHXjyRf1YMA9vv0FGimEQa dVT0zBZuayhMYiivsE4YDHM24IQbdIl8BdTHuRZUxRu0gQpTBYfHYt0SObUURxD5lJk0 mSGQ== X-Gm-Message-State: ALoCoQnowaOFQIFVGcMQoCHGIKXFY3MSI7iKzmko9EP/KYkx55Mi8yjAE6asIEKZb8/OYCeWznLO MIME-Version: 1.0 X-Received: by 10.50.43.234 with SMTP id z10mr16915388igl.28.1405521559911; Wed, 16 Jul 2014 07:39:19 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Wed, 16 Jul 2014 07:39:19 -0700 (PDT) In-Reply-To: <53C611F6.9010805@cisco.com> References: <20140715134206808664.1938077e@sniff.de> <53C611F6.9010805@cisco.com> Date: Wed, 16 Jul 2014 07:39:19 -0700 Message-ID: From: Tom Herbert To: Fabio Maino Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/yUBMulHTx5s8G3iqsXyZkZOTpS0 Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 14:39:24 -0000 Hi Fabio, thanks for your insights. On Tue, Jul 15, 2014 at 10:47 PM, Fabio Maino wrote: > Tom, > one of the design goals of GPE is to be cost effective when implemented > together with VXLAN and LISP. We do know that those are the two most > deployed protocols out there, and will be out there for quite some time > while any other network virtualization protocol gets deployed. I believe > that sharing the parsing logic across the new and legacy protocols, is a > significant reduction in complexity that eventually will help adoption of > GPE. > As I pointed there is already a lot of precedent in standard protocols that have a protocol demux and that even predate the concept of network virtualization protocols. It's still more logical to me to be consistent with them. > At the same time we want to facilitate convergence to a protocol that can be > extended with new features. Multiprotocol support and explicit service > tagging being the two most notable. > > GPE with the next protocol and version fields provides a trade off between > those two contrasting requirements. > The addition of next protocols and version field is good step with GPE, these are two of three fundamental constructs we need for extensibility. > When you consider the flexibility of GPE, you shoud look at the combination > of gpe with a shim header a-la nsh, that I believe provides the flexibility > needed to carry additional metadata. It's also my understanding that gpe+nsh > would satisfy the requirements for NIC processing that you describe in the > GUE draft. > I'm not going to rehash all the previous arguments I've made for extensibility in the encapsulation header, please look at past threads. Generally though, I'm skeptical that a variable number of fix length headers is really more palatable than a single variable length header; I know the former makes for a much more complex data path in code and increased packet overhead. Also, certain meta data like security cookie (a strict requirement in our deployment) is intrinsic to the encapsulation itself and logically part of the header. I still believe that GRE serves as the best model for a highly efficient and extensible encapsulation protocol with the only caveat that it lacks a header length field which makes it infeasible to add new fields without breaking parsing of payloads in intermediate devices. > Finally the P bit. It simply leaves open the opportunity to deploy GPE on > the same port of VXLAN (or LISP). I believe that in some deployments this > may become an advantage, that is worth the use of one bit (especially > considering that with the compact next protocol field we make available > further bits in the GPE header to future versions). > Well, as I also pointed out on this list, I don't see any way to deploy GPE on the same port as VXLAN without the risk of breaking compatibility in existing deployments. From VXLAN draft: "The other 7 bits (designated "R") are reserved fields and MUST be set to zero on transmit and ignored on receive." The requirement to ignore reserved bits on receive precludes the possibility that new bits can be implemented that change how the packet is interpreted. Note that both GUE and geneve are much more specific in this area, requiring packet to be dropped at a decapsulating host with unknown flag bits; this might be something you want to revisit in GPE spec. Thanks, Tom > Thanks, > Fabio > > > > On 7/15/14, 4:03 PM, Tom Herbert wrote: >> >> On Tue, Jul 15, 2014 at 1:42 PM, Marc Binderberger wrote: >>> >>> Hello Tom, Paul et al., >>> >>>> Abstract: technically this is not extending a VXLAN but defines a new >>>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>>> port assignment). >>> >>> (?) ... (!) interesting, the abstract was not mentioning it although it's >>> a >>> relevant change IMHO when you refer to "VxLAN". >>> >>> >>> Paul, few comments/questions: >>> >>> (1) I think the abstract should mention the requirement for a new UDP >>> port. >>> Especially as this suddenly showed up (it wasn't there in -02) >>> >>> (2) maybe a motivation why a new UDP port is needed? >>> >>> (3) propose to remove figure 3 and use figure 4 throughout the document >>> as >>> the new proposed header >>> >>> (4) does the whole P bit and "backward compatibility" makes sense? E.g. >>> in >>> 4.2 what you are doing is simply sending out a VxLAN packet according to >>> draft-mahalingam-dutt-dcops-vxlan. Not sure there is any gain explaining >>> how >>> to set P, O and protocol field. And I don't see the point in 4.1, VxLAN >>> will >>> send to it's own port, not the new one. >>> >> Right, once the protocol is using a different UDP port, there is no >> need to maintain backwards compatibility so all the deficiencies of >> VXLAN could be addressed in the "new" protocol (like the location of >> the first used flag bit, or the shift/size of the VNID). >> >> I also noticed the ambiguity if the P and O bit are simultaneously >> set. This ambiguity arises from the fact that the O bit is more a >> 1-bit type field than a flag. I would suggest donating the the O bit >> to the version field space to allow eight version/types. So val==0 >> indicates normal data packet (protocol field is present), val==1 >> indicates OAM packet. All the other fields (even flags) can be >> interpreted based on the version/type. >> >>> (5) could you provide a short motivation why you extend your flags, >>> version >>> field to the right side of the "I" flag when there is so much room on the >>> left? Sure, there is LISP - is there any problem mentioning this? >>> Elephant >>> in the room? ;-) >>> >> It's seems pretty standard to put version first in the header since >> the rest of the fields are interpreted based on that (e.g. IP). >> >>> (6) Maybe the authors of draft-quinn-vxlan-gpe had just the same idea, >>> independently but I have seen the OAM flag before: >>> draft-singh-nvo3-vxlan-router-alert. If you borrowed a good idea, why not >>> referencing? >>> >>> >>> >>> Re Tom: >>> >>>> Without P-bit we can always do simple indirect look-up to get protocol >>> >>> handler >>>> >>>> (e.g. handler = proto_handlers[protocol]) >>> >>> agree. As this will go to a new UDP port one could define the packet with >>> a >>> protocol field, always. No confusion. One precious flag saved in a fixed >>> header. >>> >>> >>>> Also, since this now has a protocol and version in the header, the >>>> only thing fundamentally missing is a header length field. Please >>>> consider adding that. See GUE >>>> (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the >>>> justification of why this is critical. >>> >>> Well, ASIC/FPGA/NP people like fixed field headers, I think. I also see >>> an >>> advantage to have an fixed 8 byte shim with similarities between VxLAN, >>> VxLAN-gpe and LISP (or LISP-gpe) from an implementation point of view. >>> The >>> hardware just needs to add 64bit from pre-programmed memory, the details >>> how >>> to fill the memory is done by the control plane. Parsing in hardware when >>> receiving a packet can also be easier (with the right layout) and be >>> shared. >>> >> Yes, it seems that fixed headers have become an implicit requirement >> in protocol design, however this conflicts with the requirement that >> protocols that are extensible. I think the answer is to define >> extensible protocols (use VLH) but assume implementations may >> optimized only a fix set of combinations (conceptually how routers >> optimize for zero length IP options, but allow packets with IP options >> in slow path). In practice, an encapsulation protocol like VXLAN is >> likely deployed in a closed network so that the encapsulation is >> uniform (only a small number of variants in encapsulation would be >> used). Introducing new fields would be a rare event, but we do need >> this capability and an preferably it should not require a new protocol >> (UDP port number) and definitely shouldn't require new HW. The ability >> to program HW with a small number of combinations of the protocol to >> parse would be awesome! :-) >> >>> Regards, Marc >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 09:21:27 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FA51A0008 for ; Wed, 16 Jul 2014 09:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 Xr5xEVrKPYkW for ; Wed, 16 Jul 2014 09:21:21 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3611A0007 for ; Wed, 16 Jul 2014 09:21:21 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so1044522igd.2 for ; Wed, 16 Jul 2014 09:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M9TGxkrGcyHU+TjJz3d2XBN4kYLN4ddj8z2ciMCnH2I=; b=MgV6DKNxDbWu+hFKAMOU9kVGXrAGcDqi3lXk4wW++kjRJZrPEike1DBqFC2p+JHZPC Rm4d/jzNT1QnOOhNijiNqSxJJlbYsxkO4pdagEqXe0QcLtymuuhKHmKeUmdeym3aw2it Pu6wpRjgHxNiPGfFyh+JuuimI7W5NUd5FSROL/raggKLInI8GYj/zdHyfL7VKGWcaAP4 OWXKJ7zcRYiI1Qh1BolA9i53Ckhv8BeQ2a6PTVdX/EIHqvCiXixBAAwMRqKmfvv7ACYA nL019CgH6WlyE//BB9lykeLaaMG5Xl0qV8s0tzFf7mLcfKFM0Gw5l6FQGC/Z8z1dHfFU jxIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M9TGxkrGcyHU+TjJz3d2XBN4kYLN4ddj8z2ciMCnH2I=; b=ip3EjnMIOkNBdVuraZI5Nw7ksssdNMhOi9UpsdJtbTIM3ts0Aev/wo2aalWfJMUS0Y T3anfu050Wwt2oFugSj11iEr5N3m5SGlT8ZUx8z+WSg/mvG3hmRc0TDKhTMv4qlZE9Fl VpE4wvQ4bQqh2nQBNPXa7T8fGrAXouhyactBBMi3icfce4nLgHomANMcKRTuvike9/9d UjHxYbyjZf6Aui666S2jHYfYvENdU3WxOSiUWwg50FnEXJV7gQ33Gm/99Yxj8LFkrkqR pi5ttmQ/f3G9vlaEGAVAROuHLhIBG78r71PyCiFGGsGoOsbhQQo0+dgwU0umwrfwFNQw geFA== X-Gm-Message-State: ALoCoQn3oY2MejIQhnvdKO/ntUJ27uNDLrGmSggEq+oZqFJXW5s/npLwnmnQhIEGGhNSrSnYsqHQ MIME-Version: 1.0 X-Received: by 10.50.43.234 with SMTP id z10mr17811919igl.28.1405527680601; Wed, 16 Jul 2014 09:21:20 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Wed, 16 Jul 2014 09:21:20 -0700 (PDT) In-Reply-To: <20140715232214444019.e52a0d56@sniff.de> References: <20140715134206808664.1938077e@sniff.de> <20140715232214444019.e52a0d56@sniff.de> Date: Wed, 16 Jul 2014 09:21:20 -0700 Message-ID: From: Tom Herbert To: Marc Binderberger Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/QO82ZDJUmwvExMSN-f2M8IToaSw Cc: "nvo3@ietf.org" , "Paul Quinn \(paulq\)" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 16:21:24 -0000 On Tue, Jul 15, 2014 at 11:22 PM, Marc Binderberger wrote: > Hello Tom, > >> I also noticed the ambiguity if the P and O bit are simultaneously >> set. This ambiguity arises from the fact that the O bit is more a >> 1-bit type field than a flag. > > well, you may have a different OAM behaviour per protocol. It's hard to say > as the details of OAM are out of scope for the document, I guess.\ > I assume that use of OAM is mutually exclusive of carrying a data packet (if this is assumption is not correct please let me know), so the format of OAM header can be completely different beyond the version/type. With this property there is no need specify any details of OAM headers now, these can be arbitrarily defined later. You can look at ICMP for a good example of using type to allow different formats for a control protocol. >> Yes, it seems that fixed headers have become an implicit requirement >> in protocol design, however this conflicts with the requirement that >> protocols that are extensible. > > well, that's where the version field comes into play. > It helps to a degree, but version numbers are an extremely finite resource and should really only be incremented when a non-backwards compatible protocol variant is introduced. The protocol should also allow for private extensions which would be valuable to allow for continued innovation-- consider that there's already been one proposal (passing MTU), which would have consumed most of the reserved bits in the encapsulation header. >> The ability >> to program HW with a small number of combinations of the protocol to >> parse would be awesome! :-) > > Agree. Assuming it's really a small number :-) > > > Regards, Marc > > > > > On Tue, 15 Jul 2014 16:03:04 -0700, Tom Herbert wrote: >> On Tue, Jul 15, 2014 at 1:42 PM, Marc Binderberger wrote: >>> Hello Tom, Paul et al., >>> >>>> Abstract: technically this is not extending a VXLAN but defines a new >>>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>>> port assignment). >>> >>> (?) ... (!) interesting, the abstract was not mentioning it although it's a >>> relevant change IMHO when you refer to "VxLAN". >>> >>> >>> Paul, few comments/questions: >>> >>> (1) I think the abstract should mention the requirement for a new UDP port. >>> Especially as this suddenly showed up (it wasn't there in -02) >>> >>> (2) maybe a motivation why a new UDP port is needed? >>> >>> (3) propose to remove figure 3 and use figure 4 throughout the document as >>> the new proposed header >>> >>> (4) does the whole P bit and "backward compatibility" makes sense? E.g. in >>> 4.2 what you are doing is simply sending out a VxLAN packet according to >>> draft-mahalingam-dutt-dcops-vxlan. Not sure there is any gain explaining >>> how >>> to set P, O and protocol field. And I don't see the point in 4.1, VxLAN >>> will >>> send to it's own port, not the new one. >>> >> Right, once the protocol is using a different UDP port, there is no >> need to maintain backwards compatibility so all the deficiencies of >> VXLAN could be addressed in the "new" protocol (like the location of >> the first used flag bit, or the shift/size of the VNID). >> >> I also noticed the ambiguity if the P and O bit are simultaneously >> set. This ambiguity arises from the fact that the O bit is more a >> 1-bit type field than a flag. I would suggest donating the the O bit >> to the version field space to allow eight version/types. So val==0 >> indicates normal data packet (protocol field is present), val==1 >> indicates OAM packet. All the other fields (even flags) can be >> interpreted based on the version/type. >> >>> (5) could you provide a short motivation why you extend your flags, version >>> field to the right side of the "I" flag when there is so much room on the >>> left? Sure, there is LISP - is there any problem mentioning this? Elephant >>> in the room? ;-) >>> >> It's seems pretty standard to put version first in the header since >> the rest of the fields are interpreted based on that (e.g. IP). >> >>> (6) Maybe the authors of draft-quinn-vxlan-gpe had just the same idea, >>> independently but I have seen the OAM flag before: >>> draft-singh-nvo3-vxlan-router-alert. If you borrowed a good idea, why not >>> referencing? >>> >>> >>> >>> Re Tom: >>> >>>> Without P-bit we can always do simple indirect look-up to get protocol >>> handler >>>> (e.g. handler = proto_handlers[protocol]) >>> >>> agree. As this will go to a new UDP port one could define the packet with a >>> protocol field, always. No confusion. One precious flag saved in a fixed >>> header. >>> >>> >>>> Also, since this now has a protocol and version in the header, the >>>> only thing fundamentally missing is a header length field. Please >>>> consider adding that. See GUE >>>> (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the >>>> justification of why this is critical. >>> >>> Well, ASIC/FPGA/NP people like fixed field headers, I think. I also see an >>> advantage to have an fixed 8 byte shim with similarities between VxLAN, >>> VxLAN-gpe and LISP (or LISP-gpe) from an implementation point of view. The >>> hardware just needs to add 64bit from pre-programmed memory, the details >>> how >>> to fill the memory is done by the control plane. Parsing in hardware when >>> receiving a packet can also be easier (with the right layout) and be >>> shared. >>> >> Yes, it seems that fixed headers have become an implicit requirement >> in protocol design, however this conflicts with the requirement that >> protocols that are extensible. I think the answer is to define >> extensible protocols (use VLH) but assume implementations may >> optimized only a fix set of combinations (conceptually how routers >> optimize for zero length IP options, but allow packets with IP options >> in slow path). In practice, an encapsulation protocol like VXLAN is >> likely deployed in a closed network so that the encapsulation is >> uniform (only a small number of variants in encapsulation would be >> used). Introducing new fields would be a rare event, but we do need >> this capability and an preferably it should not require a new protocol >> (UDP port number) and definitely shouldn't require new HW. The ability >> to program HW with a small number of combinations of the protocol to >> parse would be awesome! :-) >> >>> >>> Regards, Marc >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> From nobody Wed Jul 16 13:05:38 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28A41A0271 for ; Wed, 16 Jul 2014 13:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=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 YVFLgJWcJ9qG for ; Wed, 16 Jul 2014 13:05:34 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7B81A0011 for ; Wed, 16 Jul 2014 13:05:33 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id y10so1770017pdj.7 for ; Wed, 16 Jul 2014 13:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fU6plEzcCzeERxZ8dNGw5fLYfXjm9vbeBjQjQVks7pk=; b=MGdqOLTB2Pakstr8WlVr0orBabseVqjlX//yEOmEi39bn7esKxzR5SCHWkwX2BzQOu DIS+BHhn59I3T62ZBTPmbv4FqGHMZJYk3VXuME+Ee6dCOF44Db5gcVSYNq94Rx8B5uaI Gc9r8yA3R8YCp41cKFth3TYhr8yWu2X6rlf/wcKLht2XpuXUTrmPhbHgU9Zn1Rt5LRqp hzTbJqLot9ZcvDBEurOCWy0AaCzHE/xEUNoLJn30q+KWzbOErY3JX1JlVOI4fkfUhat+ BjPLNvQRclaka0zFRPIz0g4r752ScHb/urVzw/9J2EYg0rr/apApCuXiRZR3kd9Ftov8 /uDg== X-Received: by 10.70.96.38 with SMTP id dp6mr10031481pdb.136.1405541133581; Wed, 16 Jul 2014 13:05:33 -0700 (PDT) Received: from [192.168.5.115] (ip-64-134-231-181.public.wayport.net. [64.134.231.181]) by mx.google.com with ESMTPSA id hb11sm235197pbd.1.2014.07.16.13.05.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 13:05:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <53C612E1.1050501@cisco.com> Date: Wed, 16 Jul 2014 13:05:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/w0q9k8VuslIdrg2OcKXawTyj544 Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 20:05:36 -0000 Well, if you want to really care about customers, creating all these = variations is not doing justice to them. If you want less combinations, = you keep VXLAN the way it is right now, with no changes. You keep LISP = the way it is right now with no changes. You get L2 and L3 overlays with = a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to = the author ;-) or use BGP as an alternative push control-plane. As for NSH, you create a new header because it is completely new = requirement and has not be deployed anywhere. Since it is brand new, you = need new hardware and code to be developed to support it. So changing = VXLAN and LISP to support NSH doesn't make sense because you inject = change in 3 places rather than in 1 new place, creating more protocol = machinery, complexity, and combinations that will frustrate customers = (not to mention vendor call centers). Less entropy please, Dino On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: > Dino, > I believe that using a format that can share as much as possible with = the two protocols deployed today will give a better chance to GPE to be = implemented, as vendors may want a cost effective way to migrate to the = new protocol while preserving compatibility with legacy implementations. >=20 > The fact that GPE provides a way to be extended, either with a shim = a-la NSH or making availabe more bits in the header for future features, = I think opens up to the addition of new features (explicit service = tagging, as an example) in a more organic way than trying to use the few = bits left in VXLAN or LISP. >=20 > Unfortunately, in the LISP case, this comes to the expense of some = features that are in the current specification, but I believe those same = features can be mapped on a GPE+shim header, so a new implementation = would be able to provide the equivalent of those features (e.g. nonce). >=20 > It's hard to find the right balance between backward compatibility and = evolution of the encapsulation, but I believe GPE gets to a decent = compromise. >=20 > Thanks, > Fabio >=20 >=20 >=20 > On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>> Hi VXLAN-gpe authors, >>>>=20 >>>> Abstract: technically this is not extending a VXLAN but defines a = new >>>> protocol that looks similar to VXLAN (demonstrated by need for new = UDP >>>> port assignment). >>> We are trying to balance re-use of the VXLAN format and the need to = support existing non-GPE hardware that might already be deployed. We = looked at using the same port, and the new one, and decided, at this = point that a new port is easier for migration but since the packet = format is essentially VXLAN to keep the VXLAN name. >> Paul, this design seems to be going in circles. If a new port is = used, why not make the new port for VXLAN mean layer-3 protocols follow? = Or better yet, have a demux field after the VXLAN header so you don't = have to use VXLAN header bits. Because the P-bit is using a precious bit = in the VXLAN/LISP header and the nonce field that can be used for other = things (we have history that shows a nonce in the header is a cheap form = of obscure security). >>=20 >> If you do this then you have no compatibility problems with initial = VXLAN and LISP implementations. >>=20 >> And, most importantly, there will be less confusion in the = marketplace. >>=20 >> Dino >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 14:56:04 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196C01A032A for ; Wed, 16 Jul 2014 14:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 dVyb4O1TlHnM for ; Wed, 16 Jul 2014 14:55:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1BB1A01E7 for ; Wed, 16 Jul 2014 14:55:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHG62768; Wed, 16 Jul 2014 21:55:57 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 22:55:56 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 14:55:51 -0700 From: Linda Dunbar To: Dino Farinacci , Fabio Maino Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPoIc0wqM38Mj/Qk2Vx+TOQL5rNJuiqESAgADujID//6kqgA== Date: Wed, 16 Jul 2014 21:55:51 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9E65F@dfweml701-chm.china.huawei.com> References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> In-Reply-To: <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.213] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/oSRpVpHJCivo0udBp8L7kc3IayQ Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 21:56:01 -0000 Agree with Dino.=20 Why can't the extra information being carried by the NSH shim?=20 Linda -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci Sent: Wednesday, July 16, 2014 3:05 PM To: Fabio Maino Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxla= n-gpe-03 Well, if you want to really care about customers, creating all these variat= ions is not doing justice to them. If you want less combinations, you keep = VXLAN the way it is right now, with no changes. You keep LISP the way it is= right now with no changes. You get L2 and L3 overlays with a unified pull = control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or u= se BGP as an alternative push control-plane. As for NSH, you create a new header because it is completely new requiremen= t and has not be deployed anywhere. Since it is brand new, you need new har= dware and code to be developed to support it. So changing VXLAN and LISP to= support NSH doesn't make sense because you inject change in 3 places rathe= r than in 1 new place, creating more protocol machinery, complexity, and co= mbinations that will frustrate customers (not to mention vendor call center= s). Less entropy please, Dino On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: > Dino, > I believe that using a format that can share as much as possible with the= two protocols deployed today will give a better chance to GPE to be implem= ented, as vendors may want a cost effective way to migrate to the new proto= col while preserving compatibility with legacy implementations. >=20 > The fact that GPE provides a way to be extended, either with a shim a-la = NSH or making availabe more bits in the header for future features, I think= opens up to the addition of new features (explicit service tagging, as an = example) in a more organic way than trying to use the few bits left in VXLA= N or LISP. >=20 > Unfortunately, in the LISP case, this comes to the expense of some featur= es that are in the current specification, but I believe those same features= can be mapped on a GPE+shim header, so a new implementation would be able = to provide the equivalent of those features (e.g. nonce). >=20 > It's hard to find the right balance between backward compatibility and ev= olution of the encapsulation, but I believe GPE gets to a decent compromise= . >=20 > Thanks, > Fabio >=20 >=20 >=20 > On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>> Hi VXLAN-gpe authors, >>>>=20 >>>> Abstract: technically this is not extending a VXLAN but defines a=20 >>>> new protocol that looks similar to VXLAN (demonstrated by need for=20 >>>> new UDP port assignment). >>> We are trying to balance re-use of the VXLAN format and the need to sup= port existing non-GPE hardware that might already be deployed. We looked a= t using the same port, and the new one, and decided, at this point that a n= ew port is easier for migration but since the packet format is essentially = VXLAN to keep the VXLAN name. >> Paul, this design seems to be going in circles. If a new port is used, w= hy not make the new port for VXLAN mean layer-3 protocols follow? Or better= yet, have a demux field after the VXLAN header so you don't have to use VX= LAN header bits. Because the P-bit is using a precious bit in the VXLAN/LIS= P header and the nonce field that can be used for other things (we have his= tory that shows a nonce in the header is a cheap form of obscure security). >>=20 >> If you do this then you have no compatibility problems with initial VXLA= N and LISP implementations. >>=20 >> And, most importantly, there will be less confusion in the marketplace. >>=20 >> Dino >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 15:46:49 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D0B1A038F for ; Wed, 16 Jul 2014 15:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 A5T9RQPBe2i8 for ; Wed, 16 Jul 2014 15:46:47 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A6C1A038C for ; Wed, 16 Jul 2014 15:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4676; q=dns/txt; s=iport; t=1405550807; x=1406760407; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Hlf3YEVdjFTF46SrNzPTfEY726yObEsSFujhqRpwkcA=; b=DgInjw7kJ35TLrty1ptgFT7YMJdzMCVSKUKNWd9ZckXfttBcHlUgUDS7 gPZgeZuE1whgZXl+54WKZgfcogXEHF3+1ofE2BSqbMmPfHJExgVNP1TrQ XYLzMA1iF3ZjGCZvgKlCH4fT3tQ/Jqu1lv+3kpqkcDvCyJj97CjXD4LEb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFADcAx1OtJA2H/2dsb2JhbABagw5SV8MtCodCAYELFnaEBAEBBAEBAQsqLQkKARALGAkWDwkDAgECARUwBg0BBQIBAYg+DbFnmGkXiX6FTQeEQwEEimSQOYFMhUiNGINkHS8 X-IronPort-AV: E=Sophos;i="5.01,674,1400025600"; d="scan'208";a="340572657" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 16 Jul 2014 22:46:46 +0000 Received: from [10.21.116.164] (sjc-vpn2-1188.cisco.com [10.21.116.164]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6GMkjNg014815; Wed, 16 Jul 2014 22:46:45 GMT Message-ID: <53C700D4.9060108@cisco.com> Date: Wed, 16 Jul 2014 15:46:44 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dino Farinacci References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> In-Reply-To: <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/dHobAs1sQK_6y0TuwLbM7YeToI8 Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:46:48 -0000 Dino, GPE is not changing VXLAN nor LISP, as today's implementations cannot be changed. GPE is proposing a converged extension of both protocols that add some new features that, I believe, are needed. All of VXLAN features are supported in GPE. In the case of LISP, unfortunately, two features (nonce and map-versioning) could not be accommodated in GPE. This is not very different than any of today's LISP implementations that may decide to not support those two features (for whatever reason: cost, complexity, use cases addressed by the implementation... independently from GPE). What GPE is trying to do is to simplify next generation implementations by keeping GPE as close as possible to the existing encapsulations, adding on top of those. I maintain that an implementation supporting GPE, LISP and VXLAN will be more cost effective than one that supports VXLAN, LISP and a clean slate protocol, and may have better chances of being deployed. Fabio On 7/16/14, 1:05 PM, Dino Farinacci wrote: > Well, if you want to really care about customers, creating all these variations is not doing justice to them. If you want less combinations, you keep VXLAN the way it is right now, with no changes. You keep LISP the way it is right now with no changes. You get L2 and L3 overlays with a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or use BGP as an alternative push control-plane. > > As for NSH, you create a new header because it is completely new requirement and has not be deployed anywhere. Since it is brand new, you need new hardware and code to be developed to support it. So changing VXLAN and LISP to support NSH doesn't make sense because you inject change in 3 places rather than in 1 new place, creating more protocol machinery, complexity, and combinations that will frustrate customers (not to mention vendor call centers). > > Less entropy please, > Dino > > On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: > >> Dino, >> I believe that using a format that can share as much as possible with the two protocols deployed today will give a better chance to GPE to be implemented, as vendors may want a cost effective way to migrate to the new protocol while preserving compatibility with legacy implementations. >> >> The fact that GPE provides a way to be extended, either with a shim a-la NSH or making availabe more bits in the header for future features, I think opens up to the addition of new features (explicit service tagging, as an example) in a more organic way than trying to use the few bits left in VXLAN or LISP. >> >> Unfortunately, in the LISP case, this comes to the expense of some features that are in the current specification, but I believe those same features can be mapped on a GPE+shim header, so a new implementation would be able to provide the equivalent of those features (e.g. nonce). >> >> It's hard to find the right balance between backward compatibility and evolution of the encapsulation, but I believe GPE gets to a decent compromise. >> >> Thanks, >> Fabio >> >> >> >> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>> Hi VXLAN-gpe authors, >>>>> >>>>> Abstract: technically this is not extending a VXLAN but defines a new >>>>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>>>> port assignment). >>>> We are trying to balance re-use of the VXLAN format and the need to support existing non-GPE hardware that might already be deployed. We looked at using the same port, and the new one, and decided, at this point that a new port is easier for migration but since the packet format is essentially VXLAN to keep the VXLAN name. >>> Paul, this design seems to be going in circles. If a new port is used, why not make the new port for VXLAN mean layer-3 protocols follow? Or better yet, have a demux field after the VXLAN header so you don't have to use VXLAN header bits. Because the P-bit is using a precious bit in the VXLAN/LISP header and the nonce field that can be used for other things (we have history that shows a nonce in the header is a cheap form of obscure security). >>> >>> If you do this then you have no compatibility problems with initial VXLAN and LISP implementations. >>> >>> And, most importantly, there will be less confusion in the marketplace. >>> >>> Dino >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 15:49:58 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E091A0386 for ; Wed, 16 Jul 2014 15:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 J37uFLiDnhVP for ; Wed, 16 Jul 2014 15:49:54 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E633B1A010F for ; Wed, 16 Jul 2014 15:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4401; q=dns/txt; s=iport; t=1405550994; x=1406760594; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9Oy7c1idCyHjmlrmjnebq1I3wmEHwQh+SHSx9+xg4+w=; b=lJATOPfdp+Gr6LH2Qm1PZiHXG4l/18kRTQAXDPzTmwUUtlks2HLiZGfG PGggVaRuTdiNGSSzHqcBD/vze5KSf7tliwIvCk34Lj4tiI9YvcC4R8E28 MDp+gIw7d/8IviyuK/Zx8z4886fiHESYm7Vg+PvgkhVVGQPjR+X9X52PP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FADoBx1OtJA2L/2dsb2JhbABagw5SV8MtCodCAYELFnaEAwEBAQMBAQEBCyotAgcKAQwECxEEAQEBCRYIBwkDAgECARUfCQgGAQwBBQIBAYg2CA2xbZhoF49LBwaEPQEEimSQOYFMhUiNGINkHS8 X-IronPort-AV: E=Sophos;i="5.01,674,1400025600"; d="scan'208";a="340573273" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP; 16 Jul 2014 22:49:29 +0000 Received: from [10.21.116.164] (sjc-vpn2-1188.cisco.com [10.21.116.164]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6GMnSBT026856; Wed, 16 Jul 2014 22:49:29 GMT Message-ID: <53C70177.2000303@cisco.com> Date: Wed, 16 Jul 2014 15:49:27 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Dunbar , Dino Farinacci References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645D9E65F@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9E65F@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/9-NuVTmazm6xgvKGNLGFgLOomSs Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:49:56 -0000 On 7/16/14, 2:55 PM, Linda Dunbar wrote: > Agree with Dino. > > Why can't the extra information being carried by the NSH shim? Right. That's what we're suggesting with GPE: use a shim header, a-la NSH, to carry extra metadata and keep the basic structure of the VXLAN (and LISP, to a lesser extent) header the same. Fabio > > > Linda > > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci > Sent: Wednesday, July 16, 2014 3:05 PM > To: Fabio Maino > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 > > Well, if you want to really care about customers, creating all these variations is not doing justice to them. If you want less combinations, you keep VXLAN the way it is right now, with no changes. You keep LISP the way it is right now with no changes. You get L2 and L3 overlays with a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or use BGP as an alternative push control-plane. > > As for NSH, you create a new header because it is completely new requirement and has not be deployed anywhere. Since it is brand new, you need new hardware and code to be developed to support it. So changing VXLAN and LISP to support NSH doesn't make sense because you inject change in 3 places rather than in 1 new place, creating more protocol machinery, complexity, and combinations that will frustrate customers (not to mention vendor call centers). > > Less entropy please, > Dino > > On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: > >> Dino, >> I believe that using a format that can share as much as possible with the two protocols deployed today will give a better chance to GPE to be implemented, as vendors may want a cost effective way to migrate to the new protocol while preserving compatibility with legacy implementations. >> >> The fact that GPE provides a way to be extended, either with a shim a-la NSH or making availabe more bits in the header for future features, I think opens up to the addition of new features (explicit service tagging, as an example) in a more organic way than trying to use the few bits left in VXLAN or LISP. >> >> Unfortunately, in the LISP case, this comes to the expense of some features that are in the current specification, but I believe those same features can be mapped on a GPE+shim header, so a new implementation would be able to provide the equivalent of those features (e.g. nonce). >> >> It's hard to find the right balance between backward compatibility and evolution of the encapsulation, but I believe GPE gets to a decent compromise. >> >> Thanks, >> Fabio >> >> >> >> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>> Hi VXLAN-gpe authors, >>>>> >>>>> Abstract: technically this is not extending a VXLAN but defines a >>>>> new protocol that looks similar to VXLAN (demonstrated by need for >>>>> new UDP port assignment). >>>> We are trying to balance re-use of the VXLAN format and the need to support existing non-GPE hardware that might already be deployed. We looked at using the same port, and the new one, and decided, at this point that a new port is easier for migration but since the packet format is essentially VXLAN to keep the VXLAN name. >>> Paul, this design seems to be going in circles. If a new port is used, why not make the new port for VXLAN mean layer-3 protocols follow? Or better yet, have a demux field after the VXLAN header so you don't have to use VXLAN header bits. Because the P-bit is using a precious bit in the VXLAN/LISP header and the nonce field that can be used for other things (we have history that shows a nonce in the header is a cheap form of obscure security). >>> >>> If you do this then you have no compatibility problems with initial VXLAN and LISP implementations. >>> >>> And, most importantly, there will be less confusion in the marketplace. >>> >>> Dino >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 16:00:45 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282EC1A038E for ; Wed, 16 Jul 2014 16:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 q_6sVC9wg9Nk for ; Wed, 16 Jul 2014 16:00:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9034D1A010A for ; Wed, 16 Jul 2014 16:00:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKD00529; Wed, 16 Jul 2014 23:00:33 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Jul 2014 00:00:32 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 16:00:25 -0700 From: Lucy yong To: Fabio Maino , Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPoIczwnCC+halxEikmVbHHgu3v5uiqESAgADujICAAC0cAP//jvYg Date: Wed, 16 Jul 2014 23:00:25 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> In-Reply-To: <53C700D4.9060108@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/AKfEdNyUkmrOExnj--nM9jumm3Q Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 23:00:39 -0000 If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is a n= ew protocol, why it has to align with VXLAN format? Lucy -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fabio Maino Sent: Wednesday, July 16, 2014 5:47 PM To: Dino Farinacci Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxla= n-gpe-03 Dino, GPE is not changing VXLAN nor LISP, as today's implementations cannot be ch= anged. GPE is proposing a converged extension of both protocols that add s= ome new features that, I believe, are needed. All of VXLAN features are supported in GPE. In the case of LISP, unfortunately, two features (nonce and map-versioning) could not be accommodated in GPE. This is not very differen= t than any of today's LISP implementations that may decide to not support t= hose two features (for whatever reason: cost, complexity, use cases address= ed by the implementation... independently from GPE). What GPE is trying to do is to simplify next generation implementations by = keeping GPE as close as possible to the existing encapsulations, adding on = top of those. I maintain that an implementation supporting GPE, LISP and VX= LAN will be more cost effective than one that supports VXLAN, LISP and a cl= ean slate protocol, and may have better chances of being deployed. Fabio On 7/16/14, 1:05 PM, Dino Farinacci wrote: > Well, if you want to really care about customers, creating all these vari= ations is not doing justice to them. If you want less combinations, you kee= p VXLAN the way it is right now, with no changes. You keep LISP the way it = is right now with no changes. You get L2 and L3 overlays with a unified pul= l control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or= use BGP as an alternative push control-plane. > > As for NSH, you create a new header because it is completely new requirem= ent and has not be deployed anywhere. Since it is brand new, you need new h= ardware and code to be developed to support it. So changing VXLAN and LISP = to support NSH doesn't make sense because you inject change in 3 places rat= her than in 1 new place, creating more protocol machinery, complexity, and = combinations that will frustrate customers (not to mention vendor call cent= ers). > > Less entropy please, > Dino > > On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: > >> Dino, >> I believe that using a format that can share as much as possible with th= e two protocols deployed today will give a better chance to GPE to be imple= mented, as vendors may want a cost effective way to migrate to the new prot= ocol while preserving compatibility with legacy implementations. >> >> The fact that GPE provides a way to be extended, either with a shim a-la= NSH or making availabe more bits in the header for future features, I thin= k opens up to the addition of new features (explicit service tagging, as an= example) in a more organic way than trying to use the few bits left in VXL= AN or LISP. >> >> Unfortunately, in the LISP case, this comes to the expense of some featu= res that are in the current specification, but I believe those same feature= s can be mapped on a GPE+shim header, so a new implementation would be able= to provide the equivalent of those features (e.g. nonce). >> >> It's hard to find the right balance between backward compatibility and e= volution of the encapsulation, but I believe GPE gets to a decent compromis= e. >> >> Thanks, >> Fabio >> >> >> >> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>> Hi VXLAN-gpe authors, >>>>> >>>>> Abstract: technically this is not extending a VXLAN but defines a=20 >>>>> new protocol that looks similar to VXLAN (demonstrated by need for=20 >>>>> new UDP port assignment). >>>> We are trying to balance re-use of the VXLAN format and the need to su= pport existing non-GPE hardware that might already be deployed. We looked = at using the same port, and the new one, and decided, at this point that a = new port is easier for migration but since the packet format is essentially= VXLAN to keep the VXLAN name. >>> Paul, this design seems to be going in circles. If a new port is used, = why not make the new port for VXLAN mean layer-3 protocols follow? Or bette= r yet, have a demux field after the VXLAN header so you don't have to use V= XLAN header bits. Because the P-bit is using a precious bit in the VXLAN/LI= SP header and the nonce field that can be used for other things (we have hi= story that shows a nonce in the header is a cheap form of obscure security)= . >>> >>> If you do this then you have no compatibility problems with initial VXL= AN and LISP implementations. >>> >>> And, most importantly, there will be less confusion in the marketplace. >>> >>> Dino >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 16:38:54 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3230E1A03AB for ; Wed, 16 Jul 2014 16:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 n2OdTouO2GHp for ; Wed, 16 Jul 2014 16:38:48 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC51A0398 for ; Wed, 16 Jul 2014 16:38:48 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 16 Jul 2014 16:38:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,674,1400050800"; d="scan'208";a="570988189" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga002.fm.intel.com with ESMTP; 16 Jul 2014 16:37:33 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.106]) by ORSMSX101.amr.corp.intel.com ([169.254.8.157]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 16:37:32 -0700 From: "Elzur, Uri" To: Lucy yong , Fabio Maino , "Dino Farinacci" Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPoTFDgBtfg1uBJEWg+hReV8QKvZujwpgAgAAD04D//5IvEA== Date: Wed, 16 Jul 2014 23:37:32 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/xNp72LM5m-p0btgJ8T6rTSbJiVM Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 23:38:50 -0000 VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC provi= des guidance for. I.e. given the anticipated interpretations, with proper s= crutiny of what is allowed , VXLAN-gpe is attempting to allow for best back= wards interoperability on the existing UDP 4789 and offer best prospects fo= r carrying the additional headers/metadata. This leads to the need for new = UDP port for new formats=20 Thx =A0 Uri ("Oo-Ree") C: (949)-378-7568 -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, July 16, 2014 4:00 PM To: Fabio Maino; Dino Farinacci Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxla= n-gpe-03 If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is a n= ew protocol, why it has to align with VXLAN format? Lucy -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fabio Maino Sent: Wednesday, July 16, 2014 5:47 PM To: Dino Farinacci Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxla= n-gpe-03 Dino, GPE is not changing VXLAN nor LISP, as today's implementations cannot be ch= anged. GPE is proposing a converged extension of both protocols that add s= ome new features that, I believe, are needed. All of VXLAN features are supported in GPE. In the case of LISP, unfortunately, two features (nonce and map-versioning) could not be accommodated in GPE. This is not very differen= t than any of today's LISP implementations that may decide to not support t= hose two features (for whatever reason: cost, complexity, use cases address= ed by the implementation... independently from GPE). What GPE is trying to do is to simplify next generation implementations by = keeping GPE as close as possible to the existing encapsulations, adding on = top of those. I maintain that an implementation supporting GPE, LISP and VX= LAN will be more cost effective than one that supports VXLAN, LISP and a cl= ean slate protocol, and may have better chances of being deployed. Fabio On 7/16/14, 1:05 PM, Dino Farinacci wrote: > Well, if you want to really care about customers, creating all these vari= ations is not doing justice to them. If you want less combinations, you kee= p VXLAN the way it is right now, with no changes. You keep LISP the way it = is right now with no changes. You get L2 and L3 overlays with a unified pul= l control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or= use BGP as an alternative push control-plane. > > As for NSH, you create a new header because it is completely new requirem= ent and has not be deployed anywhere. Since it is brand new, you need new h= ardware and code to be developed to support it. So changing VXLAN and LISP = to support NSH doesn't make sense because you inject change in 3 places rat= her than in 1 new place, creating more protocol machinery, complexity, and = combinations that will frustrate customers (not to mention vendor call cent= ers). > > Less entropy please, > Dino > > On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: > >> Dino, >> I believe that using a format that can share as much as possible with th= e two protocols deployed today will give a better chance to GPE to be imple= mented, as vendors may want a cost effective way to migrate to the new prot= ocol while preserving compatibility with legacy implementations. >> >> The fact that GPE provides a way to be extended, either with a shim a-la= NSH or making availabe more bits in the header for future features, I thin= k opens up to the addition of new features (explicit service tagging, as an= example) in a more organic way than trying to use the few bits left in VXL= AN or LISP. >> >> Unfortunately, in the LISP case, this comes to the expense of some featu= res that are in the current specification, but I believe those same feature= s can be mapped on a GPE+shim header, so a new implementation would be able= to provide the equivalent of those features (e.g. nonce). >> >> It's hard to find the right balance between backward compatibility and e= volution of the encapsulation, but I believe GPE gets to a decent compromis= e. >> >> Thanks, >> Fabio >> >> >> >> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>> Hi VXLAN-gpe authors, >>>>> >>>>> Abstract: technically this is not extending a VXLAN but defines a=20 >>>>> new protocol that looks similar to VXLAN (demonstrated by need for=20 >>>>> new UDP port assignment). >>>> We are trying to balance re-use of the VXLAN format and the need to su= pport existing non-GPE hardware that might already be deployed. We looked = at using the same port, and the new one, and decided, at this point that a = new port is easier for migration but since the packet format is essentially= VXLAN to keep the VXLAN name. >>> Paul, this design seems to be going in circles. If a new port is used, = why not make the new port for VXLAN mean layer-3 protocols follow? Or bette= r yet, have a demux field after the VXLAN header so you don't have to use V= XLAN header bits. Because the P-bit is using a precious bit in the VXLAN/LI= SP header and the nonce field that can be used for other things (we have hi= story that shows a nonce in the header is a cheap form of obscure security)= . >>> >>> If you do this then you have no compatibility problems with initial VXL= AN and LISP implementations. >>> >>> And, most importantly, there will be less confusion in the marketplace. >>> >>> Dino >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 16:49:12 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB101A03A7 for ; Wed, 16 Jul 2014 16:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=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 JoToqcDeeoVF for ; Wed, 16 Jul 2014 16:49:06 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7434C1A039B for ; Wed, 16 Jul 2014 16:49:06 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so2173450pad.36 for ; Wed, 16 Jul 2014 16:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cTgznXKQeZxu3Zn65us1DG6ExWTz3HK10inoffuAK8U=; b=mvVTv3nj8wlDgCr0yb/g/gdmtmJNt62k2l2tAN1MzW+61csX0EQNGAagOXJ8AXR+It 5Rs9KS9dZ2Tb6bgTgAgHXL4u7FDP4E1d17WxTqGzm5EWiCz6dKGvcxib+HssG7Of15VL bJ0engCSDVuz1u6XfS4GXoh5loLJfmrWwb6oQxRzuOuDyMhNm4MwqoMa9HpAyNyS7s7E 9hpZUN9AV1PWELWinEL+ANsvL6w9K8sLjhd6uAP0oazKSUrNjZIDO6ughnnc+OxGeUZz SditzXGIqV+NtesVUSp75UJDbWaB7kqsw4PsAE4BJk8zP6QSWOl/rO+CIgK6gs+mPP3q G5LQ== X-Received: by 10.68.245.202 with SMTP id xq10mr24434050pbc.109.1405554546021; Wed, 16 Jul 2014 16:49:06 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id w16sm780406pdl.36.2014.07.16.16.49.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 16:49:05 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> Date: Wed, 16 Jul 2014 16:49:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> To: "Elzur, Uri" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/Qne_Z-hIttYQ_A9sDojUMxh-VjU Cc: Fabio Maino , "nvo3@ietf.org" , Lucy Yong Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 23:49:11 -0000 > VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC = provides guidance for. I.e. given the anticipated interpretations, with = proper scrutiny of what is allowed , VXLAN-gpe is attempting to allow = for best backwards interoperability on the existing UDP 4789 and offer = best prospects for carrying the additional headers/metadata. This leads = to the need for new UDP port for new formats=20 But for what features?=20 If chips can change to support L3 overlays with VXLAN, which they will = have to do L3 header parsing as well as doing L3 lookups during = recirculation, then they could just end of doing LISP. Note, the LISP = header is exactly the same as the VXLAN header so the effort is the = same. Therefore there is no point in having a P-bit and a next-header = field. As for NSH, it SHOULD have its own UDP header because you may want to = use it natively and NOT encapsulate. Again, people will find that all the parameters in NSH are really not = necessary and just creates more things the network adminstrator has to = manage and track. A service will be defined by a 5-tuple and in many = cases, all packets may have to travel across a service chain. Dino >=20 > Thx > =20 > Uri ("Oo-Ree") > C: (949)-378-7568 >=20 >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong > Sent: Wednesday, July 16, 2014 4:00 PM > To: Fabio Maino; Dino Farinacci > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Comments on = http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >=20 > If GPE is the VXLAN evolution, why it request a new UDP port? If GPE = is a new protocol, why it has to align with VXLAN format? >=20 > Lucy >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fabio Maino > Sent: Wednesday, July 16, 2014 5:47 PM > To: Dino Farinacci > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Comments on = http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >=20 > Dino, > GPE is not changing VXLAN nor LISP, as today's implementations cannot = be changed. GPE is proposing a converged extension of both protocols = that add some new features that, I believe, are needed. >=20 > All of VXLAN features are supported in GPE. >=20 > In the case of LISP, unfortunately, two features (nonce and > map-versioning) could not be accommodated in GPE. This is not very = different than any of today's LISP implementations that may decide to = not support those two features (for whatever reason: cost, complexity, = use cases addressed by the implementation... independently from GPE). >=20 > What GPE is trying to do is to simplify next generation = implementations by keeping GPE as close as possible to the existing = encapsulations, adding on top of those. I maintain that an = implementation supporting GPE, LISP and VXLAN will be more cost = effective than one that supports VXLAN, LISP and a clean slate protocol, = and may have better chances of being deployed. >=20 > Fabio >=20 >=20 > On 7/16/14, 1:05 PM, Dino Farinacci wrote: >> Well, if you want to really care about customers, creating all these = variations is not doing justice to them. If you want less combinations, = you keep VXLAN the way it is right now, with no changes. You keep LISP = the way it is right now with no changes. You get L2 and L3 overlays with = a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to = the author ;-) or use BGP as an alternative push control-plane. >>=20 >> As for NSH, you create a new header because it is completely new = requirement and has not be deployed anywhere. Since it is brand new, you = need new hardware and code to be developed to support it. So changing = VXLAN and LISP to support NSH doesn't make sense because you inject = change in 3 places rather than in 1 new place, creating more protocol = machinery, complexity, and combinations that will frustrate customers = (not to mention vendor call centers). >>=20 >> Less entropy please, >> Dino >>=20 >> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>=20 >>> Dino, >>> I believe that using a format that can share as much as possible = with the two protocols deployed today will give a better chance to GPE = to be implemented, as vendors may want a cost effective way to migrate = to the new protocol while preserving compatibility with legacy = implementations. >>>=20 >>> The fact that GPE provides a way to be extended, either with a shim = a-la NSH or making availabe more bits in the header for future features, = I think opens up to the addition of new features (explicit service = tagging, as an example) in a more organic way than trying to use the few = bits left in VXLAN or LISP. >>>=20 >>> Unfortunately, in the LISP case, this comes to the expense of some = features that are in the current specification, but I believe those same = features can be mapped on a GPE+shim header, so a new implementation = would be able to provide the equivalent of those features (e.g. nonce). >>>=20 >>> It's hard to find the right balance between backward compatibility = and evolution of the encapsulation, but I believe GPE gets to a decent = compromise. >>>=20 >>> Thanks, >>> Fabio >>>=20 >>>=20 >>>=20 >>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>> Hi VXLAN-gpe authors, >>>>>>=20 >>>>>> Abstract: technically this is not extending a VXLAN but defines a=20= >>>>>> new protocol that looks similar to VXLAN (demonstrated by need = for=20 >>>>>> new UDP port assignment). >>>>> We are trying to balance re-use of the VXLAN format and the need = to support existing non-GPE hardware that might already be deployed. We = looked at using the same port, and the new one, and decided, at this = point that a new port is easier for migration but since the packet = format is essentially VXLAN to keep the VXLAN name. >>>> Paul, this design seems to be going in circles. If a new port is = used, why not make the new port for VXLAN mean layer-3 protocols follow? = Or better yet, have a demux field after the VXLAN header so you don't = have to use VXLAN header bits. Because the P-bit is using a precious bit = in the VXLAN/LISP header and the nonce field that can be used for other = things (we have history that shows a nonce in the header is a cheap form = of obscure security). >>>>=20 >>>> If you do this then you have no compatibility problems with initial = VXLAN and LISP implementations. >>>>=20 >>>> And, most importantly, there will be less confusion in the = marketplace. >>>>=20 >>>> Dino >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 17:24:00 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F721A03AF for ; Wed, 16 Jul 2014 17:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=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 rmuwiX5T1mj1 for ; Wed, 16 Jul 2014 17:23:56 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C871A0171 for ; Wed, 16 Jul 2014 17:23:56 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y13so2065018pdi.25 for ; Wed, 16 Jul 2014 17:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OoVJi3GWqJY6tnn35RvfhRUSmboE5QjCKRVjbCPrTDA=; b=qKAur/7HQMfA7zW2XBoSvPSCeLRXlWBTQ0EMB6gayYZHcUMUW/1PwXsO0B+CDy0/Jj CbHQG62fvEQzVyXoFwh4ZNCZ7DjttQTgicLrxVOuWbi3wT0SQBjH8R6OqUH5Ap93NycS HrKAWWaVfZotJ75P7eRD/h5+fuJuahEb+5jsTEO2MlACWKmiKMMFTM4hbPhl192yf1+A 8Cb1BXKUEmq5F0HH32pP+rNKswRSHCZVKyX7tV1/XnNfAlORHNuN4PqpeEeP38eg8XhJ SOQ7n9Js5FN6f5xEfqBwqyz+nWlx11LoVgR7KS8GTZs3FaF5+2lYiWSFg3rbCYyczi9e EljA== X-Received: by 10.70.43.43 with SMTP id t11mr33339248pdl.49.1405556636356; Wed, 16 Jul 2014 17:23:56 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id fm8sm3187981pab.28.2014.07.16.17.23.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 17:23:55 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <53C700D4.9060108@cisco.com> Date: Wed, 16 Jul 2014 17:23:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52959C92-2E5A-4227-B669-66B170CE5BE0@gmail.com> References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/vRgoZ5qw8lkfQQ2P_zGNK_gItCc Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 00:23:58 -0000 > Dino, > GPE is not changing VXLAN nor LISP, as today's implementations cannot = be changed. GPE is proposing a converged extension of both protocols = that add some new features that, I believe, are needed. You change header fields, you are changing the protocol. I know you can = be compatible but you can do L2 and L3 overlays today so there is no = point in putting a protocol demux in VXLAN to do L3 overlays and a = protocol demux in LISP-4341 to do L2 overlays. > All of VXLAN features are supported in GPE. >=20 > In the case of LISP, unfortunately, two features (nonce and = map-versioning) could not be accommodated in GPE. This is not very = different than any of today's LISP implementations that may decide to = not support those two features (for whatever reason: cost, complexity, = use cases addressed by the implementation... independently from GPE). But supplying nonces is implemented pervasively. > What GPE is trying to do is to simplify next generation = implementations by keeping GPE as close as possible to the existing = encapsulations, adding on top of those. I maintain that an = implementation supporting GPE, LISP and VXLAN will be more cost = effective than one that supports VXLAN, LISP and a clean slate protocol, = and may have better chances of being deployed. I know what it is trying to do. You keep saying that but the existing = protocols already do it with no changes. So I think this change is = effectively a noop. Dino >=20 > Fabio >=20 >=20 > On 7/16/14, 1:05 PM, Dino Farinacci wrote: >> Well, if you want to really care about customers, creating all these = variations is not doing justice to them. If you want less combinations, = you keep VXLAN the way it is right now, with no changes. You keep LISP = the way it is right now with no changes. You get L2 and L3 overlays with = a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to = the author ;-) or use BGP as an alternative push control-plane. >>=20 >> As for NSH, you create a new header because it is completely new = requirement and has not be deployed anywhere. Since it is brand new, you = need new hardware and code to be developed to support it. So changing = VXLAN and LISP to support NSH doesn't make sense because you inject = change in 3 places rather than in 1 new place, creating more protocol = machinery, complexity, and combinations that will frustrate customers = (not to mention vendor call centers). >>=20 >> Less entropy please, >> Dino >>=20 >> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>=20 >>> Dino, >>> I believe that using a format that can share as much as possible = with the two protocols deployed today will give a better chance to GPE = to be implemented, as vendors may want a cost effective way to migrate = to the new protocol while preserving compatibility with legacy = implementations. >>>=20 >>> The fact that GPE provides a way to be extended, either with a shim = a-la NSH or making availabe more bits in the header for future features, = I think opens up to the addition of new features (explicit service = tagging, as an example) in a more organic way than trying to use the few = bits left in VXLAN or LISP. >>>=20 >>> Unfortunately, in the LISP case, this comes to the expense of some = features that are in the current specification, but I believe those same = features can be mapped on a GPE+shim header, so a new implementation = would be able to provide the equivalent of those features (e.g. nonce). >>>=20 >>> It's hard to find the right balance between backward compatibility = and evolution of the encapsulation, but I believe GPE gets to a decent = compromise. >>>=20 >>> Thanks, >>> Fabio >>>=20 >>>=20 >>>=20 >>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>> Hi VXLAN-gpe authors, >>>>>>=20 >>>>>> Abstract: technically this is not extending a VXLAN but defines a = new >>>>>> protocol that looks similar to VXLAN (demonstrated by need for = new UDP >>>>>> port assignment). >>>>> We are trying to balance re-use of the VXLAN format and the need = to support existing non-GPE hardware that might already be deployed. We = looked at using the same port, and the new one, and decided, at this = point that a new port is easier for migration but since the packet = format is essentially VXLAN to keep the VXLAN name. >>>> Paul, this design seems to be going in circles. If a new port is = used, why not make the new port for VXLAN mean layer-3 protocols follow? = Or better yet, have a demux field after the VXLAN header so you don't = have to use VXLAN header bits. Because the P-bit is using a precious bit = in the VXLAN/LISP header and the nonce field that can be used for other = things (we have history that shows a nonce in the header is a cheap form = of obscure security). >>>>=20 >>>> If you do this then you have no compatibility problems with initial = VXLAN and LISP implementations. >>>>=20 >>>> And, most importantly, there will be less confusion in the = marketplace. >>>>=20 >>>> Dino >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >=20 From nobody Wed Jul 16 18:07:25 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC661A03CD for ; Wed, 16 Jul 2014 18:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 X-7adbIN9ycN for ; Wed, 16 Jul 2014 18:07:21 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC35E1A03C5 for ; Wed, 16 Jul 2014 18:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5661; q=dns/txt; s=iport; t=1405559240; x=1406768840; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LjnaKaTobKLP+B2PwbdqHt5A5ntYFv8Y5o3TPqM9OQk=; b=iomX+mrfnukU/yQheoySywzY47D3H2OOQFN+bloZM2t9xYvzUsmQwbjG W67j0hgjRBvmCorny535K62tIPiNSX3xfePc+eYRmcW5TrMeEwFIhe9OG fii3Opk5grCR8vbkldeCkpq5EoQwzktRPLxbMZFsBFhMOXFduZ8ja6VNy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFABYhx1OtJA2B/2dsb2JhbABZgw5SV8MzCodCAYEIFnaEBAEBBAEBAQsqLQkKARALGAkWDwkDAgECARUwBg0BBQIBAYg+DbFemFIXiX6FTQeEQwEEimSQOYFMhUiNGINkHS8 X-IronPort-AV: E=Sophos;i="5.01,674,1400025600"; d="scan'208";a="61477526" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 17 Jul 2014 01:07:19 +0000 Received: from [10.21.116.164] (sjc-vpn2-1188.cisco.com [10.21.116.164]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6H17ISV026416; Thu, 17 Jul 2014 01:07:18 GMT Message-ID: <53C721C6.3010102@cisco.com> Date: Wed, 16 Jul 2014 18:07:18 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dino Farinacci References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <52959C92-2E5A-4227-B669-66B170CE5BE0@gmail.com> In-Reply-To: <52959C92-2E5A-4227-B669-66B170CE5BE0@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/DZ375O4Is6wLWJQA7G1gYWAyeYg Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 01:07:24 -0000 This is where we disagree Dino: we keep seeing proposals to extend the capability of network virtualization protocols. Security, as an example, is one area where even you are proposing extensions. I hope this can become an opportunity to add to the capabilities of the existing protocols while we go through the next generation of HW and SW. Fabio On 7/16/14, 5:23 PM, Dino Farinacci wrote: >> Dino, >> GPE is not changing VXLAN nor LISP, as today's implementations cannot be changed. GPE is proposing a converged extension of both protocols that add some new features that, I believe, are needed. > You change header fields, you are changing the protocol. I know you can be compatible but you can do L2 and L3 overlays today so there is no point in putting a protocol demux in VXLAN to do L3 overlays and a protocol demux in LISP-4341 to do L2 overlays. > >> All of VXLAN features are supported in GPE. >> >> In the case of LISP, unfortunately, two features (nonce and map-versioning) could not be accommodated in GPE. This is not very different than any of today's LISP implementations that may decide to not support those two features (for whatever reason: cost, complexity, use cases addressed by the implementation... independently from GPE). > But supplying nonces is implemented pervasively. > >> What GPE is trying to do is to simplify next generation implementations by keeping GPE as close as possible to the existing encapsulations, adding on top of those. I maintain that an implementation supporting GPE, LISP and VXLAN will be more cost effective than one that supports VXLAN, LISP and a clean slate protocol, and may have better chances of being deployed. > I know what it is trying to do. You keep saying that but the existing protocols already do it with no changes. So I think this change is effectively a noop. > > Dino > >> Fabio >> >> >> On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>> Well, if you want to really care about customers, creating all these variations is not doing justice to them. If you want less combinations, you keep VXLAN the way it is right now, with no changes. You keep LISP the way it is right now with no changes. You get L2 and L3 overlays with a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or use BGP as an alternative push control-plane. >>> >>> As for NSH, you create a new header because it is completely new requirement and has not be deployed anywhere. Since it is brand new, you need new hardware and code to be developed to support it. So changing VXLAN and LISP to support NSH doesn't make sense because you inject change in 3 places rather than in 1 new place, creating more protocol machinery, complexity, and combinations that will frustrate customers (not to mention vendor call centers). >>> >>> Less entropy please, >>> Dino >>> >>> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>> >>>> Dino, >>>> I believe that using a format that can share as much as possible with the two protocols deployed today will give a better chance to GPE to be implemented, as vendors may want a cost effective way to migrate to the new protocol while preserving compatibility with legacy implementations. >>>> >>>> The fact that GPE provides a way to be extended, either with a shim a-la NSH or making availabe more bits in the header for future features, I think opens up to the addition of new features (explicit service tagging, as an example) in a more organic way than trying to use the few bits left in VXLAN or LISP. >>>> >>>> Unfortunately, in the LISP case, this comes to the expense of some features that are in the current specification, but I believe those same features can be mapped on a GPE+shim header, so a new implementation would be able to provide the equivalent of those features (e.g. nonce). >>>> >>>> It's hard to find the right balance between backward compatibility and evolution of the encapsulation, but I believe GPE gets to a decent compromise. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>>> Hi VXLAN-gpe authors, >>>>>>> >>>>>>> Abstract: technically this is not extending a VXLAN but defines a new >>>>>>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>>>>>> port assignment). >>>>>> We are trying to balance re-use of the VXLAN format and the need to support existing non-GPE hardware that might already be deployed. We looked at using the same port, and the new one, and decided, at this point that a new port is easier for migration but since the packet format is essentially VXLAN to keep the VXLAN name. >>>>> Paul, this design seems to be going in circles. If a new port is used, why not make the new port for VXLAN mean layer-3 protocols follow? Or better yet, have a demux field after the VXLAN header so you don't have to use VXLAN header bits. Because the P-bit is using a precious bit in the VXLAN/LISP header and the nonce field that can be used for other things (we have history that shows a nonce in the header is a cheap form of obscure security). >>>>> >>>>> If you do this then you have no compatibility problems with initial VXLAN and LISP implementations. >>>>> >>>>> And, most importantly, there will be less confusion in the marketplace. >>>>> >>>>> Dino >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 18:10:49 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F7B1A03C7 for ; Wed, 16 Jul 2014 18:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=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 Wv4SpfskQUX0 for ; Wed, 16 Jul 2014 18:10:39 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750FC1A03C5 for ; Wed, 16 Jul 2014 18:10:39 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so681920pdj.40 for ; Wed, 16 Jul 2014 18:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Thp2ERw3k5T+Srob20/4pJTpYA8c+XNlDPE1shpmvEM=; b=xafxPLCMPWcqsT/+xRlEGbBlmJmGUsTEkDP1JNp59C0VmMP4NBjzxDP7iMlCC9raAW hLnrkJXPnGPCQQV/gnM15fRveW5ewqT1UFLZEYxRWaeKDto02wRUAdph7el43WIU3s3l FEajLu12BrF+S3Sy7pYa4bTB0jY1+0jzC9qADL+Kc8mDHJKqHhirgyiWYZ3l1rCCZUms ft7XvzLPu4BN4gzuXGTUm38ENQn6QssohLLMCLCZLjzcyR8v4uG2BIeNP8u2MfLLI/PC 7fO+aJqFU49vfyiGu9kvidplfCuBkZ55T0d66eKJfkPEbWsTI5vd2MQ/49x82/popxB3 IQmg== X-Received: by 10.69.31.193 with SMTP id ko1mr33373288pbd.40.1405559439118; Wed, 16 Jul 2014 18:10:39 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id nd10sm634541pbc.51.2014.07.16.18.10.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 18:10:38 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <53C721C6.3010102@cisco.com> Date: Wed, 16 Jul 2014 18:10:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1911E0EA-2A33-4B1C-A81F-EEB29E90CC8C@gmail.com> References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <52959C92-2E5A-4227-B669-66B170CE5BE0@gmail.com> <53C721C6.3010102@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/VYNix8M6hLfBS11-M5g91enyqi0 Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 01:10:46 -0000 > This is where we disagree Dino: we keep seeing proposals to extend the = capability of network virtualization protocols. Security, as an example, = is one area where even you are proposing extensions. I hope this can = become an opportunity to add to the capabilities of the existing = protocols while we go through the next generation of HW and SW. Please don't misunderstand: (1) We have no data-plane encryption in LISP, we are adding this. (2) We have L3 overlays with LISP, we don't need another data-plane to = do the same thing. (3) We have L2 overlays with VXLAN, we don't need another data-plane to = do the same thing. Dino >=20 > Fabio >=20 > On 7/16/14, 5:23 PM, Dino Farinacci wrote: >>> Dino, >>> GPE is not changing VXLAN nor LISP, as today's implementations = cannot be changed. GPE is proposing a converged extension of both = protocols that add some new features that, I believe, are needed. >> You change header fields, you are changing the protocol. I know you = can be compatible but you can do L2 and L3 overlays today so there is no = point in putting a protocol demux in VXLAN to do L3 overlays and a = protocol demux in LISP-4341 to do L2 overlays. >>=20 >>> All of VXLAN features are supported in GPE. >>>=20 >>> In the case of LISP, unfortunately, two features (nonce and = map-versioning) could not be accommodated in GPE. This is not very = different than any of today's LISP implementations that may decide to = not support those two features (for whatever reason: cost, complexity, = use cases addressed by the implementation... independently from GPE). >> But supplying nonces is implemented pervasively. >>=20 >>> What GPE is trying to do is to simplify next generation = implementations by keeping GPE as close as possible to the existing = encapsulations, adding on top of those. I maintain that an = implementation supporting GPE, LISP and VXLAN will be more cost = effective than one that supports VXLAN, LISP and a clean slate protocol, = and may have better chances of being deployed. >> I know what it is trying to do. You keep saying that but the existing = protocols already do it with no changes. So I think this change is = effectively a noop. >>=20 >> Dino >>=20 >>> Fabio >>>=20 >>>=20 >>> On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>>> Well, if you want to really care about customers, creating all = these variations is not doing justice to them. If you want less = combinations, you keep VXLAN the way it is right now, with no changes. = You keep LISP the way it is right now with no changes. You get L2 and L3 = overlays with a unified pull control-plane in draft-maino-nv03-lisp-cp = (preaching to the author ;-) or use BGP as an alternative push = control-plane. >>>>=20 >>>> As for NSH, you create a new header because it is completely new = requirement and has not be deployed anywhere. Since it is brand new, you = need new hardware and code to be developed to support it. So changing = VXLAN and LISP to support NSH doesn't make sense because you inject = change in 3 places rather than in 1 new place, creating more protocol = machinery, complexity, and combinations that will frustrate customers = (not to mention vendor call centers). >>>>=20 >>>> Less entropy please, >>>> Dino >>>>=20 >>>> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>>>=20 >>>>> Dino, >>>>> I believe that using a format that can share as much as possible = with the two protocols deployed today will give a better chance to GPE = to be implemented, as vendors may want a cost effective way to migrate = to the new protocol while preserving compatibility with legacy = implementations. >>>>>=20 >>>>> The fact that GPE provides a way to be extended, either with a = shim a-la NSH or making availabe more bits in the header for future = features, I think opens up to the addition of new features (explicit = service tagging, as an example) in a more organic way than trying to use = the few bits left in VXLAN or LISP. >>>>>=20 >>>>> Unfortunately, in the LISP case, this comes to the expense of some = features that are in the current specification, but I believe those same = features can be mapped on a GPE+shim header, so a new implementation = would be able to provide the equivalent of those features (e.g. nonce). >>>>>=20 >>>>> It's hard to find the right balance between backward compatibility = and evolution of the encapsulation, but I believe GPE gets to a decent = compromise. >>>>>=20 >>>>> Thanks, >>>>> Fabio >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>>>> Hi VXLAN-gpe authors, >>>>>>>>=20 >>>>>>>> Abstract: technically this is not extending a VXLAN but defines = a new >>>>>>>> protocol that looks similar to VXLAN (demonstrated by need for = new UDP >>>>>>>> port assignment). >>>>>>> We are trying to balance re-use of the VXLAN format and the need = to support existing non-GPE hardware that might already be deployed. We = looked at using the same port, and the new one, and decided, at this = point that a new port is easier for migration but since the packet = format is essentially VXLAN to keep the VXLAN name. >>>>>> Paul, this design seems to be going in circles. If a new port is = used, why not make the new port for VXLAN mean layer-3 protocols follow? = Or better yet, have a demux field after the VXLAN header so you don't = have to use VXLAN header bits. Because the P-bit is using a precious bit = in the VXLAN/LISP header and the nonce field that can be used for other = things (we have history that shows a nonce in the header is a cheap form = of obscure security). >>>>>>=20 >>>>>> If you do this then you have no compatibility problems with = initial VXLAN and LISP implementations. >>>>>>=20 >>>>>> And, most importantly, there will be less confusion in the = marketplace. >>>>>>=20 >>>>>> Dino >>>>>> _______________________________________________ >>>>>> nvo3 mailing list >>>>>> nvo3@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >=20 From nobody Wed Jul 16 18:16:49 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5641A03DE for ; Wed, 16 Jul 2014 18:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7U0LzJTZndO4 for ; Wed, 16 Jul 2014 18:16:45 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F8C1A03D9 for ; Wed, 16 Jul 2014 18:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6344; q=dns/txt; s=iport; t=1405559805; x=1406769405; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sA+/6TAF3Zsl8XFfXzp+ttMd/BJDp1hNkIe19S9BUFE=; b=RVeLQB7mM1hFOhql8O5YiODX3DsRBSQp5uvSR0vhqrlBdos+rdWs2KyU jYs+YVUfUcx1bW7ykc28183F7lBKuTgSYW5Kx858Mb8cyfzp4XNICy0fO TyB0UNg7IX7/mMt+EnWt/75rSpRbZbVQbcdUuY4Xk1i2kMhXe1GYAhe7a M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAGgjx1OtJA2B/2dsb2JhbABZgw5SV8MzCodCAYEIFnaEBAEBBAEBAQsqLQkKARALGAkWDwkDAgECARUwBg0BBQIBAYg+DbFgmFIXiX6FTQeEQwEEimSQOYFMhUiNGINkHS8 X-IronPort-AV: E=Sophos;i="5.01,674,1400025600"; d="scan'208";a="61485920" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP; 17 Jul 2014 01:16:44 +0000 Received: from [10.21.116.164] (sjc-vpn2-1188.cisco.com [10.21.116.164]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6H1GhAt030713; Thu, 17 Jul 2014 01:16:43 GMT Message-ID: <53C723FB.8070504@cisco.com> Date: Wed, 16 Jul 2014 18:16:43 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dino Farinacci References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <52959C92-2E5A-4227-B669-66B170CE5BE0@gmail.com> <53C721C6.3010102@cisco.com> <1911E0EA-2A33-4B1C-A81F-EEB29E90CC8C@gmail.com> In-Reply-To: <1911E0EA-2A33-4B1C-A81F-EEB29E90CC8C@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/Ja5RLwXxNoNFAsq2DJMHrgQgugs Cc: nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 01:16:48 -0000 But since we're respinning HW and SW to add one feature, in 2 different implementations, why don't we use this chance to converge to a single encap that can be extended to do that (and more)? Fabio On 7/16/14, 6:10 PM, Dino Farinacci wrote: >> This is where we disagree Dino: we keep seeing proposals to extend the capability of network virtualization protocols. Security, as an example, is one area where even you are proposing extensions. I hope this can become an opportunity to add to the capabilities of the existing protocols while we go through the next generation of HW and SW. > Please don't misunderstand: > > (1) We have no data-plane encryption in LISP, we are adding this. > (2) We have L3 overlays with LISP, we don't need another data-plane to do the same thing. > (3) We have L2 overlays with VXLAN, we don't need another data-plane to do the same thing. > > Dino > >> Fabio >> >> On 7/16/14, 5:23 PM, Dino Farinacci wrote: >>>> Dino, >>>> GPE is not changing VXLAN nor LISP, as today's implementations cannot be changed. GPE is proposing a converged extension of both protocols that add some new features that, I believe, are needed. >>> You change header fields, you are changing the protocol. I know you can be compatible but you can do L2 and L3 overlays today so there is no point in putting a protocol demux in VXLAN to do L3 overlays and a protocol demux in LISP-4341 to do L2 overlays. >>> >>>> All of VXLAN features are supported in GPE. >>>> >>>> In the case of LISP, unfortunately, two features (nonce and map-versioning) could not be accommodated in GPE. This is not very different than any of today's LISP implementations that may decide to not support those two features (for whatever reason: cost, complexity, use cases addressed by the implementation... independently from GPE). >>> But supplying nonces is implemented pervasively. >>> >>>> What GPE is trying to do is to simplify next generation implementations by keeping GPE as close as possible to the existing encapsulations, adding on top of those. I maintain that an implementation supporting GPE, LISP and VXLAN will be more cost effective than one that supports VXLAN, LISP and a clean slate protocol, and may have better chances of being deployed. >>> I know what it is trying to do. You keep saying that but the existing protocols already do it with no changes. So I think this change is effectively a noop. >>> >>> Dino >>> >>>> Fabio >>>> >>>> >>>> On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>>>> Well, if you want to really care about customers, creating all these variations is not doing justice to them. If you want less combinations, you keep VXLAN the way it is right now, with no changes. You keep LISP the way it is right now with no changes. You get L2 and L3 overlays with a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or use BGP as an alternative push control-plane. >>>>> >>>>> As for NSH, you create a new header because it is completely new requirement and has not be deployed anywhere. Since it is brand new, you need new hardware and code to be developed to support it. So changing VXLAN and LISP to support NSH doesn't make sense because you inject change in 3 places rather than in 1 new place, creating more protocol machinery, complexity, and combinations that will frustrate customers (not to mention vendor call centers). >>>>> >>>>> Less entropy please, >>>>> Dino >>>>> >>>>> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>>>> >>>>>> Dino, >>>>>> I believe that using a format that can share as much as possible with the two protocols deployed today will give a better chance to GPE to be implemented, as vendors may want a cost effective way to migrate to the new protocol while preserving compatibility with legacy implementations. >>>>>> >>>>>> The fact that GPE provides a way to be extended, either with a shim a-la NSH or making availabe more bits in the header for future features, I think opens up to the addition of new features (explicit service tagging, as an example) in a more organic way than trying to use the few bits left in VXLAN or LISP. >>>>>> >>>>>> Unfortunately, in the LISP case, this comes to the expense of some features that are in the current specification, but I believe those same features can be mapped on a GPE+shim header, so a new implementation would be able to provide the equivalent of those features (e.g. nonce). >>>>>> >>>>>> It's hard to find the right balance between backward compatibility and evolution of the encapsulation, but I believe GPE gets to a decent compromise. >>>>>> >>>>>> Thanks, >>>>>> Fabio >>>>>> >>>>>> >>>>>> >>>>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>>>>> Hi VXLAN-gpe authors, >>>>>>>>> >>>>>>>>> Abstract: technically this is not extending a VXLAN but defines a new >>>>>>>>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>>>>>>>> port assignment). >>>>>>>> We are trying to balance re-use of the VXLAN format and the need to support existing non-GPE hardware that might already be deployed. We looked at using the same port, and the new one, and decided, at this point that a new port is easier for migration but since the packet format is essentially VXLAN to keep the VXLAN name. >>>>>>> Paul, this design seems to be going in circles. If a new port is used, why not make the new port for VXLAN mean layer-3 protocols follow? Or better yet, have a demux field after the VXLAN header so you don't have to use VXLAN header bits. Because the P-bit is using a precious bit in the VXLAN/LISP header and the nonce field that can be used for other things (we have history that shows a nonce in the header is a cheap form of obscure security). >>>>>>> >>>>>>> If you do this then you have no compatibility problems with initial VXLAN and LISP implementations. >>>>>>> >>>>>>> And, most importantly, there will be less confusion in the marketplace. >>>>>>> >>>>>>> Dino >>>>>>> _______________________________________________ >>>>>>> nvo3 mailing list >>>>>>> nvo3@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>>> _______________________________________________ >>>>>> nvo3 mailing list >>>>>> nvo3@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 18:27:37 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E701A03EC for ; Wed, 16 Jul 2014 18:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=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 fhB7YfkkV2R0 for ; Wed, 16 Jul 2014 18:27:35 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287FC1A03E4 for ; Wed, 16 Jul 2014 18:27:35 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so2319071pab.30 for ; Wed, 16 Jul 2014 18:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HFaF9yLtsme65xg51/IOSG91xZTmJhWmxpYkW8fAKpg=; b=DNyDeVsKHKQSfEQsr6zM3YGQb4NL9HXPEOrwqIAlxZju9uFY4PpKGiw1C7kinF4AZ1 mAbXtqo+jtcBmGwaAA5n1waBUNxs08yUcR5WqgZqAkb9W5QABYsF1gjpLhqOtkUTEw6h xXdC8Q8irGzfBrW3ev/RScSoT54vm/h4M2bjW7IIN3qgvQbZ1Ckt6PNjJKDBwwtIWjdP 2coAnbuEmJBXTboXQObDQLM5l3YJlRGlyOzHaWA7eiEO6EyqQTGWY0J5fcrngr7mqYu7 kxTTo7mTyBmcuD06VgqPDrg7E+neEPa1j2NvC7E8n//sHpBt/nPxvUjLdaTBQ8bnCW1y yrmg== X-Received: by 10.66.150.228 with SMTP id ul4mr33604732pab.16.1405560454806; Wed, 16 Jul 2014 18:27:34 -0700 (PDT) Received: from [192.168.1.34] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id by1sm651420pbb.75.2014.07.16.18.27.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 18:27:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: <53C723FB.8070504@cisco.com> Date: Wed, 16 Jul 2014 18:27:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6AB1E019-D4C8-4E9B-8E39-3978C2CF776C@gmail.com> References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <52959C92-2E5A-4227-B669-66B170CE5BE0@gmail.com> <53C721C6.3010102@cisco.com> <1911E0EA-2A33-4B1C-A81F-EEB29E90CC8C@gmail.com> <53C723FB.8070504@cisco.com> To: Fabio Maino Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/v_idzRMj8hODjY4lnjfjQTDG5s8 Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 01:27:37 -0000 > On Jul 16, 2014, at 6:16 PM, Fabio Maino wrote: >=20 > But since we're respinning HW and SW to add one feature, in 2 different im= plementations, why don't we use this chance to converge to a single encap th= at can be extended to do that (and more)? Because users have older products from cisco and other vendors who are deplo= ying overlays now. So the decision is already made about which encapsulation= format to use for which type of overlay.=20 Focusing on NSH (only) is a good thing because that is a transport independe= nt service chaining feature that does not already exist.=20 Dino >=20 > Fabio >=20 > On 7/16/14, 6:10 PM, Dino Farinacci wrote: >>> This is where we disagree Dino: we keep seeing proposals to extend the c= apability of network virtualization protocols. Security, as an example, is o= ne area where even you are proposing extensions. I hope this can become an o= pportunity to add to the capabilities of the existing protocols while we go t= hrough the next generation of HW and SW. >> Please don't misunderstand: >>=20 >> (1) We have no data-plane encryption in LISP, we are adding this. >> (2) We have L3 overlays with LISP, we don't need another data-plane to do= the same thing. >> (3) We have L2 overlays with VXLAN, we don't need another data-plane to d= o the same thing. >>=20 >> Dino >>=20 >>> Fabio >>>=20 >>> On 7/16/14, 5:23 PM, Dino Farinacci wrote: >>>>> Dino, >>>>> GPE is not changing VXLAN nor LISP, as today's implementations cannot b= e changed. GPE is proposing a converged extension of both protocols that ad= d some new features that, I believe, are needed. >>>> You change header fields, you are changing the protocol. I know you can= be compatible but you can do L2 and L3 overlays today so there is no point i= n putting a protocol demux in VXLAN to do L3 overlays and a protocol demux i= n LISP-4341 to do L2 overlays. >>>>=20 >>>>> All of VXLAN features are supported in GPE. >>>>>=20 >>>>> In the case of LISP, unfortunately, two features (nonce and map-versio= ning) could not be accommodated in GPE. This is not very different than any o= f today's LISP implementations that may decide to not support those two feat= ures (for whatever reason: cost, complexity, use cases addressed by the impl= ementation... independently from GPE). >>>> But supplying nonces is implemented pervasively. >>>>=20 >>>>> What GPE is trying to do is to simplify next generation implementation= s by keeping GPE as close as possible to the existing encapsulations, adding= on top of those. I maintain that an implementation supporting GPE, LISP and= VXLAN will be more cost effective than one that supports VXLAN, LISP and a c= lean slate protocol, and may have better chances of being deployed. >>>> I know what it is trying to do. You keep saying that but the existing p= rotocols already do it with no changes. So I think this change is effectivel= y a noop. >>>>=20 >>>> Dino >>>>=20 >>>>> Fabio >>>>>=20 >>>>>=20 >>>>>> On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>>>>> Well, if you want to really care about customers, creating all these v= ariations is not doing justice to them. If you want less combinations, you k= eep VXLAN the way it is right now, with no changes. You keep LISP the way it= is right now with no changes. You get L2 and L3 overlays with a unified pul= l control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or u= se BGP as an alternative push control-plane. >>>>>>=20 >>>>>> As for NSH, you create a new header because it is completely new requ= irement and has not be deployed anywhere. Since it is brand new, you need ne= w hardware and code to be developed to support it. So changing VXLAN and LIS= P to support NSH doesn't make sense because you inject change in 3 places ra= ther than in 1 new place, creating more protocol machinery, complexity, and c= ombinations that will frustrate customers (not to mention vendor call center= s). >>>>>>=20 >>>>>> Less entropy please, >>>>>> Dino >>>>>>=20 >>>>>>> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>>>>>>=20 >>>>>>> Dino, >>>>>>> I believe that using a format that can share as much as possible wit= h the two protocols deployed today will give a better chance to GPE to be im= plemented, as vendors may want a cost effective way to migrate to the new pr= otocol while preserving compatibility with legacy implementations. >>>>>>>=20 >>>>>>> The fact that GPE provides a way to be extended, either with a shim a= -la NSH or making availabe more bits in the header for future features, I th= ink opens up to the addition of new features (explicit service tagging, as a= n example) in a more organic way than trying to use the few bits left in VXL= AN or LISP. >>>>>>>=20 >>>>>>> Unfortunately, in the LISP case, this comes to the expense of some f= eatures that are in the current specification, but I believe those same feat= ures can be mapped on a GPE+shim header, so a new implementation would be ab= le to provide the equivalent of those features (e.g. nonce). >>>>>>>=20 >>>>>>> It's hard to find the right balance between backward compatibility a= nd evolution of the encapsulation, but I believe GPE gets to a decent compro= mise. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Fabio >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>>>>>> Hi VXLAN-gpe authors, >>>>>>>>>>=20 >>>>>>>>>> Abstract: technically this is not extending a VXLAN but defines a= new >>>>>>>>>> protocol that looks similar to VXLAN (demonstrated by need for ne= w UDP >>>>>>>>>> port assignment). >>>>>>>>> We are trying to balance re-use of the VXLAN format and the need t= o support existing non-GPE hardware that might already be deployed. We look= ed at using the same port, and the new one, and decided, at this point that a= new port is easier for migration but since the packet format is essentially= VXLAN to keep the VXLAN name. >>>>>>>> Paul, this design seems to be going in circles. If a new port is us= ed, why not make the new port for VXLAN mean layer-3 protocols follow? Or be= tter yet, have a demux field after the VXLAN header so you don't have to use= VXLAN header bits. Because the P-bit is using a precious bit in the VXLAN/L= ISP header and the nonce field that can be used for other things (we have hi= story that shows a nonce in the header is a cheap form of obscure security).= >>>>>>>>=20 >>>>>>>> If you do this then you have no compatibility problems with initial= VXLAN and LISP implementations. >>>>>>>>=20 >>>>>>>> And, most importantly, there will be less confusion in the marketpl= ace. >>>>>>>>=20 >>>>>>>> Dino >>>>>>>> _______________________________________________ >>>>>>>> nvo3 mailing list >>>>>>>> nvo3@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>>>> _______________________________________________ >>>>>>> nvo3 mailing list >>>>>>> nvo3@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >=20 From nobody Wed Jul 16 21:12:02 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2EC1A058E for ; Wed, 16 Jul 2014 21:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 QRZSTZ3q3DSW for ; Wed, 16 Jul 2014 21:11:51 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CADC31A04E7 for ; Wed, 16 Jul 2014 21:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7280; q=dns/txt; s=iport; t=1405570312; x=1406779912; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4+qi1FxZC9eqR7+5CBny/16NeHyRWf/6YLms3WBS6RQ=; b=LUuRkf0pWqRoXkTVmIKTE/X92rdr0DiFSdhcMtla+61JkCVHjMZtHTSm x+GgCEpW7CVcTbAaFXsUOB/xekEsKwsBqzOJwSIkXgm/99oodZB4vWJqI 93042W2rW/0pzlT1LR5o8EAjLt47JHnuFI7i8IdhR42S66oPB4DW0Xcel I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFADRMx1OtJA2G/2dsb2JhbABZgw5SV8M0CodCAYEJFnaEAwEBAQMBAQEBCyotCQoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBiDYIDbFmmEoXiX6FTQeEQwEEimSQOYFMhUiNGINkHS8 X-IronPort-AV: E=Sophos;i="5.01,675,1400025600"; d="scan'208";a="340607436" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jul 2014 04:11:50 +0000 Received: from [10.21.66.61] (sjc-vpn3-573.cisco.com [10.21.66.61]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6H4BnbL000437; Thu, 17 Jul 2014 04:11:49 GMT Message-ID: <53C74D04.1080404@cisco.com> Date: Wed, 16 Jul 2014 21:11:48 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dino Farinacci References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <52959C92-2E5A-4227-B669-66B170CE5BE0@gmail.com> <53C721C6.3010102@cisco.com> <1911E0EA-2A33-4B1C-A81F-EEB29E90CC8C@gmail.com> <53C723FB.8070504@cisco.com> <6AB1E019-D4C8-4E9B-8E39-3978C2CF776C@gmail.com> In-Reply-To: <6AB1E019-D4C8-4E9B-8E39-3978C2CF776C@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/_8t4anGJdbGgLkI8TowCobjwJtE Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 04:11:59 -0000 On 7/16/14, 6:27 PM, Dino Farinacci wrote: > >> On Jul 16, 2014, at 6:16 PM, Fabio Maino wrote: >> >> But since we're respinning HW and SW to add one feature, in 2 different implementations, why don't we use this chance to converge to a single encap that can be extended to do that (and more)? > Because users have older products from cisco and other vendors who are deploying overlays now. So the decision is already made about which encapsulation format to use for which type of overlay. and this is why we are proposing to use a common encap that is an extension of the two deployed today. A new implementation, with minimal complexity, will be able to support VXLAN, LISP (for compatibility with installed base) and GPE augmented with the features that may be needed. Fabio > > Focusing on NSH (only) is a good thing because that is a transport independent service chaining feature that does not already exist. > > Dino > >> Fabio >> >> On 7/16/14, 6:10 PM, Dino Farinacci wrote: >>>> This is where we disagree Dino: we keep seeing proposals to extend the capability of network virtualization protocols. Security, as an example, is one area where even you are proposing extensions. I hope this can become an opportunity to add to the capabilities of the existing protocols while we go through the next generation of HW and SW. >>> Please don't misunderstand: >>> >>> (1) We have no data-plane encryption in LISP, we are adding this. >>> (2) We have L3 overlays with LISP, we don't need another data-plane to do the same thing. >>> (3) We have L2 overlays with VXLAN, we don't need another data-plane to do the same thing. >>> >>> Dino >>> >>>> Fabio >>>> >>>> On 7/16/14, 5:23 PM, Dino Farinacci wrote: >>>>>> Dino, >>>>>> GPE is not changing VXLAN nor LISP, as today's implementations cannot be changed. GPE is proposing a converged extension of both protocols that add some new features that, I believe, are needed. >>>>> You change header fields, you are changing the protocol. I know you can be compatible but you can do L2 and L3 overlays today so there is no point in putting a protocol demux in VXLAN to do L3 overlays and a protocol demux in LISP-4341 to do L2 overlays. >>>>> >>>>>> All of VXLAN features are supported in GPE. >>>>>> >>>>>> In the case of LISP, unfortunately, two features (nonce and map-versioning) could not be accommodated in GPE. This is not very different than any of today's LISP implementations that may decide to not support those two features (for whatever reason: cost, complexity, use cases addressed by the implementation... independently from GPE). >>>>> But supplying nonces is implemented pervasively. >>>>> >>>>>> What GPE is trying to do is to simplify next generation implementations by keeping GPE as close as possible to the existing encapsulations, adding on top of those. I maintain that an implementation supporting GPE, LISP and VXLAN will be more cost effective than one that supports VXLAN, LISP and a clean slate protocol, and may have better chances of being deployed. >>>>> I know what it is trying to do. You keep saying that but the existing protocols already do it with no changes. So I think this change is effectively a noop. >>>>> >>>>> Dino >>>>> >>>>>> Fabio >>>>>> >>>>>> >>>>>>> On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>>>>>> Well, if you want to really care about customers, creating all these variations is not doing justice to them. If you want less combinations, you keep VXLAN the way it is right now, with no changes. You keep LISP the way it is right now with no changes. You get L2 and L3 overlays with a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or use BGP as an alternative push control-plane. >>>>>>> >>>>>>> As for NSH, you create a new header because it is completely new requirement and has not be deployed anywhere. Since it is brand new, you need new hardware and code to be developed to support it. So changing VXLAN and LISP to support NSH doesn't make sense because you inject change in 3 places rather than in 1 new place, creating more protocol machinery, complexity, and combinations that will frustrate customers (not to mention vendor call centers). >>>>>>> >>>>>>> Less entropy please, >>>>>>> Dino >>>>>>> >>>>>>>> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>>>>>>> >>>>>>>> Dino, >>>>>>>> I believe that using a format that can share as much as possible with the two protocols deployed today will give a better chance to GPE to be implemented, as vendors may want a cost effective way to migrate to the new protocol while preserving compatibility with legacy implementations. >>>>>>>> >>>>>>>> The fact that GPE provides a way to be extended, either with a shim a-la NSH or making availabe more bits in the header for future features, I think opens up to the addition of new features (explicit service tagging, as an example) in a more organic way than trying to use the few bits left in VXLAN or LISP. >>>>>>>> >>>>>>>> Unfortunately, in the LISP case, this comes to the expense of some features that are in the current specification, but I believe those same features can be mapped on a GPE+shim header, so a new implementation would be able to provide the equivalent of those features (e.g. nonce). >>>>>>>> >>>>>>>> It's hard to find the right balance between backward compatibility and evolution of the encapsulation, but I believe GPE gets to a decent compromise. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Fabio >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>>>>>>> Hi VXLAN-gpe authors, >>>>>>>>>>> >>>>>>>>>>> Abstract: technically this is not extending a VXLAN but defines a new >>>>>>>>>>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>>>>>>>>>> port assignment). >>>>>>>>>> We are trying to balance re-use of the VXLAN format and the need to support existing non-GPE hardware that might already be deployed. We looked at using the same port, and the new one, and decided, at this point that a new port is easier for migration but since the packet format is essentially VXLAN to keep the VXLAN name. >>>>>>>>> Paul, this design seems to be going in circles. If a new port is used, why not make the new port for VXLAN mean layer-3 protocols follow? Or better yet, have a demux field after the VXLAN header so you don't have to use VXLAN header bits. Because the P-bit is using a precious bit in the VXLAN/LISP header and the nonce field that can be used for other things (we have history that shows a nonce in the header is a cheap form of obscure security). >>>>>>>>> >>>>>>>>> If you do this then you have no compatibility problems with initial VXLAN and LISP implementations. >>>>>>>>> >>>>>>>>> And, most importantly, there will be less confusion in the marketplace. >>>>>>>>> >>>>>>>>> Dino >>>>>>>>> _______________________________________________ >>>>>>>>> nvo3 mailing list >>>>>>>>> nvo3@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>>>>> _______________________________________________ >>>>>>>> nvo3 mailing list >>>>>>>> nvo3@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 16 21:55:29 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207B31A0645 for ; Wed, 16 Jul 2014 21:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 u9iN-k1zoWKj for ; Wed, 16 Jul 2014 21:55:23 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666861A063F for ; Wed, 16 Jul 2014 21:55:23 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id uq10so2108929igb.11 for ; Wed, 16 Jul 2014 21:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Mh6QtWAmUQ4bconEw9hnVNBI3VCOfvNXx88SOHh+ic=; b=Q8GQMMiZ0ho2FghmM8Pmksjb69w0bqB6PpZ+1jerrPL0fH/novw+uSBh+RtqKtB1/I XlD0WV243Q3K+/1AwOuEJ8/2jng/t/Mr81ZSGgrm9di8hePCfjaQ2wW8UAf2Ybl5ci7W p7dCg8ZeYHhUlf4mnUmN4cGpOasY1hWrUE3RwTJQ6TvGLGfq+hmO/na8otJNk7CAM/LL ILB8MHFKuL+9nmdwSZp1GIIg4vag2y4pSXNPw+jU4J/H1I1vsbPl4pKxU9zBdvt7d0Dm 9TlVDb8k3F9ZHUS3+uR2FG3EYksusfBiClgqZDOEjgjoU1nX6HRXyG2N0lf5QZhw2e+W Zhqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4Mh6QtWAmUQ4bconEw9hnVNBI3VCOfvNXx88SOHh+ic=; b=KNKderFBMVgGL+uhou97MNQSUcWEj9Ouoqz4pNYBpkUdVSgrzN+l2fUfshJC/CElxz TlYNZPHFRvOcFBClxC3JmDZzRI3+Oz/BmT/ZnpeTGRVp9ZcnodPryAWrFY69MI4XCXRR EHNBYuH+En6C1uhflUGGbx0t8SP6hkWl8Fu9Vvhs2Br1F6iQAu10b9iPLqhmjJc83o6z f8m3oW4+lw+nGv8p/Tqel3pW3ULuboLUdaux/u+RnqQnx2w8E5ZCUqK7I54Lz534eS3g ml985ZprszSwJ7htSb2R5hdGrTjSZM48qxlrL//Ofva2JqpXJGNTtIwUU7zf0Q9Y4U/Z ZLNg== X-Gm-Message-State: ALoCoQk7cskKwJKAFY0fB9kS8aev0gVRNpyZJf8XkQ8DCpyvE+HL0GcaJERF4jNOz39Dad7ANXbN MIME-Version: 1.0 X-Received: by 10.50.25.196 with SMTP id e4mr23272441igg.28.1405572922391; Wed, 16 Jul 2014 21:55:22 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Wed, 16 Jul 2014 21:55:22 -0700 (PDT) In-Reply-To: <53C611F6.9010805@cisco.com> References: <20140715134206808664.1938077e@sniff.de> <53C611F6.9010805@cisco.com> Date: Wed, 16 Jul 2014 21:55:22 -0700 Message-ID: From: Tom Herbert To: Fabio Maino Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/0zNZsdkhD_i6YMgs1TkyMtFpsmQ Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 04:55:27 -0000 > When you consider the flexibility of GPE, you shoud look at the combination > of gpe with a shim header a-la nsh, that I believe provides the flexibility > needed to carry additional metadata. It's also my understanding that gpe+nsh > would satisfy the requirements for NIC processing that you describe in the > GUE draft. > I am very uncertain whether nsh could meet our requirements, I don't see that nsh provides an adequate model for extensibility in this case. The meta data we've conceived thus far-- security, congestion control, and VNID (which to me is just an instance ofmeta data) are primary for end to end use. The necessary consumer of this is only the decapsulation point, but we allow the possibility that intermediate devices inspect this data but not change it (if we implement strong authentication of the header, intermediate nodes won't be able to change it at all). Additionally, the data we need for this is not at all a set of idempotent items-- for instance the purpose of a security cookie is to validate the vnid, they go to together. A decapsulating host must validate the security token be accepting the packet, so in nsh it seems we would need to forward parse headers in order to process the first header. Also, we need security (or CRC validation) to cover all the meta data, I don't know how that could work in nsh. The other concern I'd have is how to make this performant. This a very low level protocol and the thought of walking these chains on every packet is unpleasant. That we'd need to do this even in cases where we just want to parse the encapsulated packet or find a specific field (like security) makes it seem really unpleasant. Maybe it's possible to make this parsing super fast in HW, but I don't see how to make this efficient in SW at least compared to an much simpler model like in GRE. Admittedly, my understanding of nsh is pretty limited-- seems like there's a lot of functionality in it but also a lot of complexity. A real example demonstrating all the packet headers for some use with VXLAN-gpe would be quite helpful-- maybe the formats for sending a 64 bit security cookie could be enlightening. Thanks, Tom > Finally the P bit. It simply leaves open the opportunity to deploy GPE on > the same port of VXLAN (or LISP). I believe that in some deployments this > may become an advantage, that is worth the use of one bit (especially > considering that with the compact next protocol field we make available > further bits in the GPE header to future versions). > > > Thanks, > Fabio > > > > On 7/15/14, 4:03 PM, Tom Herbert wrote: >> >> On Tue, Jul 15, 2014 at 1:42 PM, Marc Binderberger wrote: >>> >>> Hello Tom, Paul et al., >>> >>>> Abstract: technically this is not extending a VXLAN but defines a new >>>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>>> port assignment). >>> >>> (?) ... (!) interesting, the abstract was not mentioning it although it's >>> a >>> relevant change IMHO when you refer to "VxLAN". >>> >>> >>> Paul, few comments/questions: >>> >>> (1) I think the abstract should mention the requirement for a new UDP >>> port. >>> Especially as this suddenly showed up (it wasn't there in -02) >>> >>> (2) maybe a motivation why a new UDP port is needed? >>> >>> (3) propose to remove figure 3 and use figure 4 throughout the document >>> as >>> the new proposed header >>> >>> (4) does the whole P bit and "backward compatibility" makes sense? E.g. >>> in >>> 4.2 what you are doing is simply sending out a VxLAN packet according to >>> draft-mahalingam-dutt-dcops-vxlan. Not sure there is any gain explaining >>> how >>> to set P, O and protocol field. And I don't see the point in 4.1, VxLAN >>> will >>> send to it's own port, not the new one. >>> >> Right, once the protocol is using a different UDP port, there is no >> need to maintain backwards compatibility so all the deficiencies of >> VXLAN could be addressed in the "new" protocol (like the location of >> the first used flag bit, or the shift/size of the VNID). >> >> I also noticed the ambiguity if the P and O bit are simultaneously >> set. This ambiguity arises from the fact that the O bit is more a >> 1-bit type field than a flag. I would suggest donating the the O bit >> to the version field space to allow eight version/types. So val==0 >> indicates normal data packet (protocol field is present), val==1 >> indicates OAM packet. All the other fields (even flags) can be >> interpreted based on the version/type. >> >>> (5) could you provide a short motivation why you extend your flags, >>> version >>> field to the right side of the "I" flag when there is so much room on the >>> left? Sure, there is LISP - is there any problem mentioning this? >>> Elephant >>> in the room? ;-) >>> >> It's seems pretty standard to put version first in the header since >> the rest of the fields are interpreted based on that (e.g. IP). >> >>> (6) Maybe the authors of draft-quinn-vxlan-gpe had just the same idea, >>> independently but I have seen the OAM flag before: >>> draft-singh-nvo3-vxlan-router-alert. If you borrowed a good idea, why not >>> referencing? >>> >>> >>> >>> Re Tom: >>> >>>> Without P-bit we can always do simple indirect look-up to get protocol >>> >>> handler >>>> >>>> (e.g. handler = proto_handlers[protocol]) >>> >>> agree. As this will go to a new UDP port one could define the packet with >>> a >>> protocol field, always. No confusion. One precious flag saved in a fixed >>> header. >>> >>> >>>> Also, since this now has a protocol and version in the header, the >>>> only thing fundamentally missing is a header length field. Please >>>> consider adding that. See GUE >>>> (http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the >>>> justification of why this is critical. >>> >>> Well, ASIC/FPGA/NP people like fixed field headers, I think. I also see >>> an >>> advantage to have an fixed 8 byte shim with similarities between VxLAN, >>> VxLAN-gpe and LISP (or LISP-gpe) from an implementation point of view. >>> The >>> hardware just needs to add 64bit from pre-programmed memory, the details >>> how >>> to fill the memory is done by the control plane. Parsing in hardware when >>> receiving a packet can also be easier (with the right layout) and be >>> shared. >>> >> Yes, it seems that fixed headers have become an implicit requirement >> in protocol design, however this conflicts with the requirement that >> protocols that are extensible. I think the answer is to define >> extensible protocols (use VLH) but assume implementations may >> optimized only a fix set of combinations (conceptually how routers >> optimize for zero length IP options, but allow packets with IP options >> in slow path). In practice, an encapsulation protocol like VXLAN is >> likely deployed in a closed network so that the encapsulation is >> uniform (only a small number of variants in encapsulation would be >> used). Introducing new fields would be a rare event, but we do need >> this capability and an preferably it should not require a new protocol >> (UDP port number) and definitely shouldn't require new HW. The ability >> to program HW with a small number of combinations of the protocol to >> parse would be awesome! :-) >> >>> Regards, Marc >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Thu Jul 17 06:27:06 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FA91A0B09 for ; Thu, 17 Jul 2014 06:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.003 X-Spam-Level: X-Spam-Status: No, score=-12.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 yuPwXR0jl8Rw for ; Thu, 17 Jul 2014 06:27:02 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011D31A0B00 for ; Thu, 17 Jul 2014 06:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6953; q=dns/txt; s=iport; t=1405603622; x=1406813222; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PAVJPPaQBC5iB4pu+0a9AvMPJTDRT2OkhviZwcM5Hf8=; b=B0n8zSPuj3i+cbHevA0pxDZ2oCGRX8KniKRRJfWqFXRzrPUQP/33SAWe YxpOn5vIiq/N39L6SdTe+flqf9ivboSe/LFboXT6HswuKqnrk71T21im3 3ED+Ys/t8HsKCrP/nrJ0ebFyY7OXsPuVie9x2h1WWRt316g2EeaZk5VdZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAPTOx1OtJA2D/2dsb2JhbABWA4MOUlcEw0YKh0IBgQUWdoQDAQEBBAEBAQssKwkLDAQCAQgRBAEBAR4JBycLFAkIAgQBDQUbiCcNrWOYNBeJfoU9EAcGC4Q1BZsfgUySYINEbIFF X-IronPort-AV: E=Sophos;i="5.01,678,1400025600"; d="scan'208";a="61647180" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP; 17 Jul 2014 13:27:01 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6HDR1M8023066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 13:27:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 08:27:00 -0500 From: "Ken Gray (kegray)" To: "Elzur, Uri" , Lucy yong , "Fabio Maino (fmaino)" , Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPoIcv52CRsFKJJk+o6RAtLGqiepuihr2AgADujICAAC0cAIAAA9OAgAAKXwCAAKSwgA== Date: Thu, 17 Jul 2014 13:27:00 +0000 Message-ID: References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.217] Content-Type: text/plain; charset="us-ascii" Content-ID: <942D27FCE463BF4C8F09A97718D4C4B0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/lpoa80CNIN3QUI80N02-vJI0N-8 Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 13:27:04 -0000 Where Dino and I agree, and not to pick on Uri - I've seen the statement "additional headers/metadata" a few times now and it STILL sounds like "work around SFC", particularly in respect to the metadata part (since passing metadata was one of SFC's points). If you want to tilt at that windmill, I don't think that binding the solution to a particular transport encap is the optimal way to do it (if you can avoid doing so). On 7/16/14 7:37 PM, "Elzur, Uri" wrote: >VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC >provides guidance for. I.e. given the anticipated interpretations, with >proper scrutiny of what is allowed , VXLAN-gpe is attempting to allow for >best backwards interoperability on the existing UDP 4789 and offer best >prospects for carrying the additional headers/metadata. This leads to the >need for new UDP port for new formats > >Thx >=20 >Uri ("Oo-Ree") >C: (949)-378-7568 > > >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >Sent: Wednesday, July 16, 2014 4:00 PM >To: Fabio Maino; Dino Farinacci >Cc: nvo3@ietf.org >Subject: Re: [nvo3] Comments on >http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 > >If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is a >new protocol, why it has to align with VXLAN format? > >Lucy > >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fabio Maino >Sent: Wednesday, July 16, 2014 5:47 PM >To: Dino Farinacci >Cc: nvo3@ietf.org >Subject: Re: [nvo3] Comments on >http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 > >Dino, >GPE is not changing VXLAN nor LISP, as today's implementations cannot be >changed. GPE is proposing a converged extension of both protocols that >add some new features that, I believe, are needed. > >All of VXLAN features are supported in GPE. > >In the case of LISP, unfortunately, two features (nonce and >map-versioning) could not be accommodated in GPE. This is not very >different than any of today's LISP implementations that may decide to not >support those two features (for whatever reason: cost, complexity, use >cases addressed by the implementation... independently from GPE). > >What GPE is trying to do is to simplify next generation implementations >by keeping GPE as close as possible to the existing encapsulations, >adding on top of those. I maintain that an implementation supporting GPE, >LISP and VXLAN will be more cost effective than one that supports VXLAN, >LISP and a clean slate protocol, and may have better chances of being >deployed. > >Fabio > > >On 7/16/14, 1:05 PM, Dino Farinacci wrote: >> Well, if you want to really care about customers, creating all these >>variations is not doing justice to them. If you want less combinations, >>you keep VXLAN the way it is right now, with no changes. You keep LISP >>the way it is right now with no changes. You get L2 and L3 overlays with >>a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to >>the author ;-) or use BGP as an alternative push control-plane. >> >> As for NSH, you create a new header because it is completely new >>requirement and has not be deployed anywhere. Since it is brand new, you >>need new hardware and code to be developed to support it. So changing >>VXLAN and LISP to support NSH doesn't make sense because you inject >>change in 3 places rather than in 1 new place, creating more protocol >>machinery, complexity, and combinations that will frustrate customers >>(not to mention vendor call centers). >> >> Less entropy please, >> Dino >> >> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >> >>> Dino, >>> I believe that using a format that can share as much as possible with >>>the two protocols deployed today will give a better chance to GPE to be >>>implemented, as vendors may want a cost effective way to migrate to the >>>new protocol while preserving compatibility with legacy implementations. >>> >>> The fact that GPE provides a way to be extended, either with a shim >>>a-la NSH or making availabe more bits in the header for future >>>features, I think opens up to the addition of new features (explicit >>>service tagging, as an example) in a more organic way than trying to >>>use the few bits left in VXLAN or LISP. >>> >>> Unfortunately, in the LISP case, this comes to the expense of some >>>features that are in the current specification, but I believe those >>>same features can be mapped on a GPE+shim header, so a new >>>implementation would be able to provide the equivalent of those >>>features (e.g. nonce). >>> >>> It's hard to find the right balance between backward compatibility and >>>evolution of the encapsulation, but I believe GPE gets to a decent >>>compromise. >>> >>> Thanks, >>> Fabio >>> >>> >>> >>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>> Hi VXLAN-gpe authors, >>>>>> >>>>>> Abstract: technically this is not extending a VXLAN but defines a >>>>>> new protocol that looks similar to VXLAN (demonstrated by need for >>>>>> new UDP port assignment). >>>>> We are trying to balance re-use of the VXLAN format and the need to >>>>>support existing non-GPE hardware that might already be deployed. We >>>>>looked at using the same port, and the new one, and decided, at this >>>>>point that a new port is easier for migration but since the packet >>>>>format is essentially VXLAN to keep the VXLAN name. >>>> Paul, this design seems to be going in circles. If a new port is >>>>used, why not make the new port for VXLAN mean layer-3 protocols >>>>follow? Or better yet, have a demux field after the VXLAN header so >>>>you don't have to use VXLAN header bits. Because the P-bit is using a >>>>precious bit in the VXLAN/LISP header and the nonce field that can be >>>>used for other things (we have history that shows a nonce in the >>>>header is a cheap form of obscure security). >>>> >>>> If you do this then you have no compatibility problems with initial >>>>VXLAN and LISP implementations. >>>> >>>> And, most importantly, there will be less confusion in the >>>>marketplace. >>>> >>>> Dino >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From nobody Thu Jul 17 08:39:10 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0CD1ADDC7 for ; Thu, 17 Jul 2014 08:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.78 X-Spam-Level: X-Spam-Status: No, score=-0.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 UvV6_8HTDxOp for ; Thu, 17 Jul 2014 08:39:06 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24C11A0AE3 for ; Thu, 17 Jul 2014 08:39:05 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id c1so6386200igq.13 for ; Thu, 17 Jul 2014 08:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ee0yYuNpKffEPP17Pddx99QX0ZvrJEUTlLIi0ApDj14=; b=h11eUPg041fIXBdPo8EAVrWwpoODRZdK0/b3eVlCuoIBRBmAtJqhsjTrZt0yVaVJz3 rhy/kBi+fbCj9ZNs2Of6jriqEMTtNFVBZJh2QMfo/RuRIyMA/JL3vtniJonyB8xZe4G7 TfFjTkcbljoybPLP0P+PhFdMfHzJ09Nvq7hPTsXuhGluq1MD43+eEQ1sweAZ5HAm9UKI IDUX4Vl7p/PVIxJnjn1zQXag/Qq7LSt2VSiBPDvRFqULPZwXHWqcOnXY28br5FPwgjiE KQvC7/OIXMheQEoqOgsTt9boGQNTb0k19GkYDjYI7F3xvUpS8cQnzVTL5v2Li85/ZZoO 7L8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ee0yYuNpKffEPP17Pddx99QX0ZvrJEUTlLIi0ApDj14=; b=ggcwZFcdK9Y95hOpGWGmBWXSzDvmlho4np8+z4vbOg0Z065HjFtRtxCUw9+UIGAAJy xmK0bRSQb/8JK6f0q0muwCksOediYOyKwAkkxsNyVkuw6UJUzBbGWLbhEZoThKnnYuEp fL/tAXtTUPZAuIHinOGsL30xuOalAL/BrjB3GkeOybMLF7NEFWMaGJTNdJHRcLwmNdeB 11xWPQ7IT47H/ODpJ/aGdH5FQR36sgejfErYRKfUNXhNLyBENDCgS72mlJe2G/0cMBCL wdZCdVJOJxYi2WHfkP2VAfmLLbqO6Pf9kzx2n8cEJFdfDe2dOj0X1fd29pHJyVC94PXJ b5sg== X-Gm-Message-State: ALoCoQnYEIUV15FpFxwOG34EoF9kvlAzoMllXU6LTVy0lh2Hxa0DnDvjvVAvJRzMvzbf6bKXN7Uq MIME-Version: 1.0 X-Received: by 10.50.12.38 with SMTP id v6mr28771496igb.29.1405611545012; Thu, 17 Jul 2014 08:39:05 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Thu, 17 Jul 2014 08:39:04 -0700 (PDT) In-Reply-To: References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> Date: Thu, 17 Jul 2014 08:39:04 -0700 Message-ID: From: Tom Herbert To: "Ken Gray (kegray)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/KHSdypR7UVybtldNriPfzpLU42w Cc: "Elzur, Uri" , "Fabio Maino \(fmaino\)" , "nvo3@ietf.org" , Dino Farinacci , Lucy yong Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:39:07 -0000 On Thu, Jul 17, 2014 at 6:27 AM, Ken Gray (kegray) wrote: > Where Dino and I agree, and not to pick on Uri - I've seen the statement > "additional headers/metadata" a few times now and it STILL sounds like > "work around SFC", particularly in respect to the metadata part (since > passing metadata was one of SFC's points). > > If you want to tilt at that windmill, I don't think that binding the > solution to a particular transport encap is the optimal way to do it (if > you can avoid doing so). > By this line of thinking TCP options should be moved to extension headers. If the meta data is part of the transport protocol and needed for its operation then it's should be within the transport header not buried at some other place in the packet. There's already a lot of precedent for this in IETF protocols and we had more than thirty years of operational experience dealing with optional data in several core protocols. I really don't see that the encapsulation protocol case is so unique that a new model needs to be adopted. > On 7/16/14 7:37 PM, "Elzur, Uri" wrote: > >>VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC >>provides guidance for. I.e. given the anticipated interpretations, with >>proper scrutiny of what is allowed , VXLAN-gpe is attempting to allow for >>best backwards interoperability on the existing UDP 4789 and offer best >>prospects for carrying the additional headers/metadata. This leads to the >>need for new UDP port for new formats >> >>Thx >> >>Uri ("Oo-Ree") >>C: (949)-378-7568 >> >> >>-----Original Message----- >>From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >>Sent: Wednesday, July 16, 2014 4:00 PM >>To: Fabio Maino; Dino Farinacci >>Cc: nvo3@ietf.org >>Subject: Re: [nvo3] Comments on >>http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >> >>If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is a >>new protocol, why it has to align with VXLAN format? >> >>Lucy >> >>-----Original Message----- >>From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fabio Maino >>Sent: Wednesday, July 16, 2014 5:47 PM >>To: Dino Farinacci >>Cc: nvo3@ietf.org >>Subject: Re: [nvo3] Comments on >>http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >> >>Dino, >>GPE is not changing VXLAN nor LISP, as today's implementations cannot be >>changed. GPE is proposing a converged extension of both protocols that >>add some new features that, I believe, are needed. >> >>All of VXLAN features are supported in GPE. >> >>In the case of LISP, unfortunately, two features (nonce and >>map-versioning) could not be accommodated in GPE. This is not very >>different than any of today's LISP implementations that may decide to not >>support those two features (for whatever reason: cost, complexity, use >>cases addressed by the implementation... independently from GPE). >> >>What GPE is trying to do is to simplify next generation implementations >>by keeping GPE as close as possible to the existing encapsulations, >>adding on top of those. I maintain that an implementation supporting GPE, >>LISP and VXLAN will be more cost effective than one that supports VXLAN, >>LISP and a clean slate protocol, and may have better chances of being >>deployed. >> >>Fabio >> >> >>On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>> Well, if you want to really care about customers, creating all these >>>variations is not doing justice to them. If you want less combinations, >>>you keep VXLAN the way it is right now, with no changes. You keep LISP >>>the way it is right now with no changes. You get L2 and L3 overlays with >>>a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to >>>the author ;-) or use BGP as an alternative push control-plane. >>> >>> As for NSH, you create a new header because it is completely new >>>requirement and has not be deployed anywhere. Since it is brand new, you >>>need new hardware and code to be developed to support it. So changing >>>VXLAN and LISP to support NSH doesn't make sense because you inject >>>change in 3 places rather than in 1 new place, creating more protocol >>>machinery, complexity, and combinations that will frustrate customers >>>(not to mention vendor call centers). >>> >>> Less entropy please, >>> Dino >>> >>> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>> >>>> Dino, >>>> I believe that using a format that can share as much as possible with >>>>the two protocols deployed today will give a better chance to GPE to be >>>>implemented, as vendors may want a cost effective way to migrate to the >>>>new protocol while preserving compatibility with legacy implementations. >>>> >>>> The fact that GPE provides a way to be extended, either with a shim >>>>a-la NSH or making availabe more bits in the header for future >>>>features, I think opens up to the addition of new features (explicit >>>>service tagging, as an example) in a more organic way than trying to >>>>use the few bits left in VXLAN or LISP. >>>> >>>> Unfortunately, in the LISP case, this comes to the expense of some >>>>features that are in the current specification, but I believe those >>>>same features can be mapped on a GPE+shim header, so a new >>>>implementation would be able to provide the equivalent of those >>>>features (e.g. nonce). >>>> >>>> It's hard to find the right balance between backward compatibility and >>>>evolution of the encapsulation, but I believe GPE gets to a decent >>>>compromise. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>>> Hi VXLAN-gpe authors, >>>>>>> >>>>>>> Abstract: technically this is not extending a VXLAN but defines a >>>>>>> new protocol that looks similar to VXLAN (demonstrated by need for >>>>>>> new UDP port assignment). >>>>>> We are trying to balance re-use of the VXLAN format and the need to >>>>>>support existing non-GPE hardware that might already be deployed. We >>>>>>looked at using the same port, and the new one, and decided, at this >>>>>>point that a new port is easier for migration but since the packet >>>>>>format is essentially VXLAN to keep the VXLAN name. >>>>> Paul, this design seems to be going in circles. If a new port is >>>>>used, why not make the new port for VXLAN mean layer-3 protocols >>>>>follow? Or better yet, have a demux field after the VXLAN header so >>>>>you don't have to use VXLAN header bits. Because the P-bit is using a >>>>>precious bit in the VXLAN/LISP header and the nonce field that can be >>>>>used for other things (we have history that shows a nonce in the >>>>>header is a cheap form of obscure security). >>>>> >>>>> If you do this then you have no compatibility problems with initial >>>>>VXLAN and LISP implementations. >>>>> >>>>> And, most importantly, there will be less confusion in the >>>>>marketplace. >>>>> >>>>> Dino >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >> >>_______________________________________________ >>nvo3 mailing list >>nvo3@ietf.org >>https://www.ietf.org/mailman/listinfo/nvo3 >> >>_______________________________________________ >>nvo3 mailing list >>nvo3@ietf.org >>https://www.ietf.org/mailman/listinfo/nvo3 >> >>_______________________________________________ >>nvo3 mailing list >>nvo3@ietf.org >>https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Thu Jul 17 08:41:22 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FC51B27B2 for ; Thu, 17 Jul 2014 08:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 jCnTiXPk8orr for ; Thu, 17 Jul 2014 08:41:16 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE5C1B27AD for ; Thu, 17 Jul 2014 08:41:09 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id r10so1891580pdi.34 for ; Thu, 17 Jul 2014 08:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CM7kWfwW9wPQJDJ8v73EsDZqLiouKiYt42nAZsXazIY=; b=d2MA/y+DbqC/02Z12t2Mc+3TYUUPUToWxfi57/9lVt/ujSTDWn/xtbPK/pgSLn1mop /faJOEIxmBDTNiGE/so9KAwvco0HINhsw4KpHPQzJFskxG7Q7NhQqe+Q83baTPPp8AN6 SbQCDAcax7sIA/Y0WFO90M+zpYQyLLLaqbYl8/Pfw2PvJzAQmQQ8rUjRYMT/MdjUKLeI 7+0xA9RDzzZuI2eUF/Xsrup1b54Aafb142vouOsq2Rp/zZ4xEPMOePhxzUUrbEJ+GeGv LI7JFeN5kazBGYv1/V7PcoLU82sYzpiGpHrJgfCIsJpSS1EglkpUipgFHUduPRX0IAE4 R+dw== X-Received: by 10.66.132.69 with SMTP id os5mr3673441pab.134.1405611669298; Thu, 17 Jul 2014 08:41:09 -0700 (PDT) Received: from [192.168.1.114] ([207.145.253.66]) by mx.google.com with ESMTPSA id fn1sm2864038pbc.77.2014.07.17.08.41.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jul 2014 08:41:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: Date: Thu, 17 Jul 2014 08:41:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <40A85A0E-B193-4C29-ABDA-C71BA28FAC2C@gmail.com> References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> To: Tom Herbert X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/07SoMfv6FiPY0H_DFZRlGvvwFuU Cc: "Elzur, Uri" , Fabio Maino , "nvo3@ietf.org" , "Ken Gray \(kegray\)" , Lucy Yong Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:41:19 -0000 > On Thu, Jul 17, 2014 at 6:27 AM, Ken Gray (kegray) = wrote: >> Where Dino and I agree, and not to pick on Uri - I've seen the = statement >> "additional headers/metadata" a few times now and it STILL sounds = like >> "work around SFC", particularly in respect to the metadata part = (since >> passing metadata was one of SFC's points). >>=20 >> If you want to tilt at that windmill, I don't think that binding the >> solution to a particular transport encap is the optimal way to do it = (if >> you can avoid doing so). >>=20 > By this line of thinking TCP options should be moved to extension > headers. If the meta data is part of the transport protocol and needed > for its operation then it's should be within the transport header not > buried at some other place in the packet. There's already a lot of > precedent for this in IETF protocols and we had more than thirty years > of operational experience dealing with optional data in several core > protocols. I really don't see that the encapsulation protocol case is > so unique that a new model needs to be adopted. Well stated and 100% agree. Dino From nobody Thu Jul 17 09:00:41 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C481A0033 for ; Thu, 17 Jul 2014 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Z1qHPF5Bf-3i for ; Thu, 17 Jul 2014 09:00:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2060A1B27B9 for ; Thu, 17 Jul 2014 09:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7412; q=dns/txt; s=iport; t=1405612819; x=1406822419; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b4uSjA8/dq/6FnvJV4xf1A63vwCLfzUUQApWcm7gLWo=; b=ksA4bSTNlRAAfbnUx0XLYbqQJD6Uyb8VlK+OBUfBVhiqL04GLeEPw1wW 3xDpyAWjANGF8RIoI9xhVhxbRu0Rw4m5h8G5RvqReoVwjBB3mRoR2Wfr7 SFqrfvNkU90aSf6+pUdlx4kVSBHQICGpSfcccZ1Eiwf7FTumv74YZR6OG 4=; X-IronPort-AV: E=Sophos;i="5.01,679,1400025600"; d="scan'208";a="340767662" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jul 2014 16:00:18 +0000 Received: from [10.21.146.88] (sjc-vpn7-600.cisco.com [10.21.146.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6HG0F8a005266; Thu, 17 Jul 2014 16:00:16 GMT Message-ID: <53C7F30F.7010501@cisco.com> Date: Thu, 17 Jul 2014 09:00:15 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Ken Gray (kegray)" , "Elzur, Uri" , Lucy yong , Dino Farinacci References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/foz2H-6H5QyO0XsrXKIIkFv0sno Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:00:20 -0000 Ken, there is no intent to tie SFC to this transport, rather to make this transport capable to handle those (and possibly other) metadata. Fabio On 7/17/14, 6:27 AM, Ken Gray (kegray) wrote: > Where Dino and I agree, and not to pick on Uri - I've seen the statement > "additional headers/metadata" a few times now and it STILL sounds like > "work around SFC", particularly in respect to the metadata part (since > passing metadata was one of SFC's points). > > If you want to tilt at that windmill, I don't think that binding the > solution to a particular transport encap is the optimal way to do it (if > you can avoid doing so). > > On 7/16/14 7:37 PM, "Elzur, Uri" wrote: > >> VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC >> provides guidance for. I.e. given the anticipated interpretations, with >> proper scrutiny of what is allowed , VXLAN-gpe is attempting to allow for >> best backwards interoperability on the existing UDP 4789 and offer best >> prospects for carrying the additional headers/metadata. This leads to the >> need for new UDP port for new formats >> >> Thx >> >> Uri ("Oo-Ree") >> C: (949)-378-7568 >> >> >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >> Sent: Wednesday, July 16, 2014 4:00 PM >> To: Fabio Maino; Dino Farinacci >> Cc: nvo3@ietf.org >> Subject: Re: [nvo3] Comments on >> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >> >> If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is a >> new protocol, why it has to align with VXLAN format? >> >> Lucy >> >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fabio Maino >> Sent: Wednesday, July 16, 2014 5:47 PM >> To: Dino Farinacci >> Cc: nvo3@ietf.org >> Subject: Re: [nvo3] Comments on >> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >> >> Dino, >> GPE is not changing VXLAN nor LISP, as today's implementations cannot be >> changed. GPE is proposing a converged extension of both protocols that >> add some new features that, I believe, are needed. >> >> All of VXLAN features are supported in GPE. >> >> In the case of LISP, unfortunately, two features (nonce and >> map-versioning) could not be accommodated in GPE. This is not very >> different than any of today's LISP implementations that may decide to not >> support those two features (for whatever reason: cost, complexity, use >> cases addressed by the implementation... independently from GPE). >> >> What GPE is trying to do is to simplify next generation implementations >> by keeping GPE as close as possible to the existing encapsulations, >> adding on top of those. I maintain that an implementation supporting GPE, >> LISP and VXLAN will be more cost effective than one that supports VXLAN, >> LISP and a clean slate protocol, and may have better chances of being >> deployed. >> >> Fabio >> >> >> On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>> Well, if you want to really care about customers, creating all these >>> variations is not doing justice to them. If you want less combinations, >>> you keep VXLAN the way it is right now, with no changes. You keep LISP >>> the way it is right now with no changes. You get L2 and L3 overlays with >>> a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to >>> the author ;-) or use BGP as an alternative push control-plane. >>> >>> As for NSH, you create a new header because it is completely new >>> requirement and has not be deployed anywhere. Since it is brand new, you >>> need new hardware and code to be developed to support it. So changing >>> VXLAN and LISP to support NSH doesn't make sense because you inject >>> change in 3 places rather than in 1 new place, creating more protocol >>> machinery, complexity, and combinations that will frustrate customers >>> (not to mention vendor call centers). >>> >>> Less entropy please, >>> Dino >>> >>> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>> >>>> Dino, >>>> I believe that using a format that can share as much as possible with >>>> the two protocols deployed today will give a better chance to GPE to be >>>> implemented, as vendors may want a cost effective way to migrate to the >>>> new protocol while preserving compatibility with legacy implementations. >>>> >>>> The fact that GPE provides a way to be extended, either with a shim >>>> a-la NSH or making availabe more bits in the header for future >>>> features, I think opens up to the addition of new features (explicit >>>> service tagging, as an example) in a more organic way than trying to >>>> use the few bits left in VXLAN or LISP. >>>> >>>> Unfortunately, in the LISP case, this comes to the expense of some >>>> features that are in the current specification, but I believe those >>>> same features can be mapped on a GPE+shim header, so a new >>>> implementation would be able to provide the equivalent of those >>>> features (e.g. nonce). >>>> >>>> It's hard to find the right balance between backward compatibility and >>>> evolution of the encapsulation, but I believe GPE gets to a decent >>>> compromise. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>>> Hi VXLAN-gpe authors, >>>>>>> >>>>>>> Abstract: technically this is not extending a VXLAN but defines a >>>>>>> new protocol that looks similar to VXLAN (demonstrated by need for >>>>>>> new UDP port assignment). >>>>>> We are trying to balance re-use of the VXLAN format and the need to >>>>>> support existing non-GPE hardware that might already be deployed. We >>>>>> looked at using the same port, and the new one, and decided, at this >>>>>> point that a new port is easier for migration but since the packet >>>>>> format is essentially VXLAN to keep the VXLAN name. >>>>> Paul, this design seems to be going in circles. If a new port is >>>>> used, why not make the new port for VXLAN mean layer-3 protocols >>>>> follow? Or better yet, have a demux field after the VXLAN header so >>>>> you don't have to use VXLAN header bits. Because the P-bit is using a >>>>> precious bit in the VXLAN/LISP header and the nonce field that can be >>>>> used for other things (we have history that shows a nonce in the >>>>> header is a cheap form of obscure security). >>>>> >>>>> If you do this then you have no compatibility problems with initial >>>>> VXLAN and LISP implementations. >>>>> >>>>> And, most importantly, there will be less confusion in the >>>>> marketplace. >>>>> >>>>> Dino >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From nobody Thu Jul 17 09:02:39 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BAE1A0176 for ; Thu, 17 Jul 2014 09:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ddGvG0FXUBnz for ; Thu, 17 Jul 2014 09:02:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53561A0033 for ; Thu, 17 Jul 2014 09:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7856; q=dns/txt; s=iport; t=1405612942; x=1406822542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ORTIDgDawJoF2xZehsYwg1Yu8zD48ukNnNaHv3C1KvM=; b=P/COg8Ulkf8eCuTGuvTNq6LkQ+iZLDMouYG8cjS3oEIhEQmuvpm+XPrT UVlOzXT3pnJysoQ9I9+eVn5zAr4DRUHoMW1PD/Orj6oToLDeHXhOvmfvO AcmkKf1ESz4wcUmjIrpYDYmv66zgqhLxheY5yAJ2Vq3O6d/e8pRdjTFtO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAEnzx1OtJA2K/2dsb2JhbABWA4MOUlcEw0YKh0IBgQcWdoQDAQEBBAEBAQtXCQsMBAIBCBEEAQEBJwcnCxQJCAIEAQ0FG4gnDa0pmDcXiX6FPRAHBguENQWbH4FMkmCDRGyBRQ X-IronPort-AV: E=Sophos;i="5.01,679,1400025600"; d="scan'208";a="340734718" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2014 16:02:04 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6HG24u4019894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 16:02:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 11:02:03 -0500 From: "Ken Gray (kegray)" To: "Fabio Maino (fmaino)" , "Elzur, Uri" , Lucy yong , Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPoIcv52CRsFKJJk+o6RAtLGqiepuihr2AgADujICAAC0cAIAAA9OAgAAKXwCAAKSwgIAAbeGA//+9bwA= Date: Thu, 17 Jul 2014 16:02:03 +0000 Message-ID: References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> <53C7F30F.7010501@cisco.com> In-Reply-To: <53C7F30F.7010501@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.217] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/M13l5SqLHdAcS38mQsxTfFA9iu4 Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:02:25 -0000 The other authors have graciously made that clear. Thanks. (Never write before coffee =8Anever) On 7/17/14 12:00 PM, "Fabio Maino (fmaino)" wrote: >Ken, >there is no intent to tie SFC to this transport, rather to make this >transport capable to handle those (and possibly other) metadata. > >Fabio > >On 7/17/14, 6:27 AM, Ken Gray (kegray) wrote: >> Where Dino and I agree, and not to pick on Uri - I've seen the statement >> "additional headers/metadata" a few times now and it STILL sounds like >> "work around SFC", particularly in respect to the metadata part (since >> passing metadata was one of SFC's points). >> >> If you want to tilt at that windmill, I don't think that binding the >> solution to a particular transport encap is the optimal way to do it (if >> you can avoid doing so). >> >> On 7/16/14 7:37 PM, "Elzur, Uri" wrote: >> >>> VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC >>> provides guidance for. I.e. given the anticipated interpretations, with >>> proper scrutiny of what is allowed , VXLAN-gpe is attempting to allow >>>for >>> best backwards interoperability on the existing UDP 4789 and offer best >>> prospects for carrying the additional headers/metadata. This leads to >>>the >>> need for new UDP port for new formats >>> >>> Thx >>> >>> Uri ("Oo-Ree") >>> C: (949)-378-7568 >>> >>> >>> -----Original Message----- >>> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >>> Sent: Wednesday, July 16, 2014 4:00 PM >>> To: Fabio Maino; Dino Farinacci >>> Cc: nvo3@ietf.org >>> Subject: Re: [nvo3] Comments on >>> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>> >>> If GPE is the VXLAN evolution, why it request a new UDP port? If GPE >>>is a >>> new protocol, why it has to align with VXLAN format? >>> >>> Lucy >>> >>> -----Original Message----- >>> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fabio Maino >>> Sent: Wednesday, July 16, 2014 5:47 PM >>> To: Dino Farinacci >>> Cc: nvo3@ietf.org >>> Subject: Re: [nvo3] Comments on >>> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>> >>> Dino, >>> GPE is not changing VXLAN nor LISP, as today's implementations cannot >>>be >>> changed. GPE is proposing a converged extension of both protocols that >>> add some new features that, I believe, are needed. >>> >>> All of VXLAN features are supported in GPE. >>> >>> In the case of LISP, unfortunately, two features (nonce and >>> map-versioning) could not be accommodated in GPE. This is not very >>> different than any of today's LISP implementations that may decide to >>>not >>> support those two features (for whatever reason: cost, complexity, use >>> cases addressed by the implementation... independently from GPE). >>> >>> What GPE is trying to do is to simplify next generation implementations >>> by keeping GPE as close as possible to the existing encapsulations, >>> adding on top of those. I maintain that an implementation supporting >>>GPE, >>> LISP and VXLAN will be more cost effective than one that supports >>>VXLAN, >>> LISP and a clean slate protocol, and may have better chances of being >>> deployed. >>> >>> Fabio >>> >>> >>> On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>>> Well, if you want to really care about customers, creating all these >>>> variations is not doing justice to them. If you want less >>>>combinations, >>>> you keep VXLAN the way it is right now, with no changes. You keep LISP >>>> the way it is right now with no changes. You get L2 and L3 overlays >>>>with >>>> a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to >>>> the author ;-) or use BGP as an alternative push control-plane. >>>> >>>> As for NSH, you create a new header because it is completely new >>>> requirement and has not be deployed anywhere. Since it is brand new, >>>>you >>>> need new hardware and code to be developed to support it. So changing >>>> VXLAN and LISP to support NSH doesn't make sense because you inject >>>> change in 3 places rather than in 1 new place, creating more protocol >>>> machinery, complexity, and combinations that will frustrate customers >>>> (not to mention vendor call centers). >>>> >>>> Less entropy please, >>>> Dino >>>> >>>> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>>> >>>>> Dino, >>>>> I believe that using a format that can share as much as possible with >>>>> the two protocols deployed today will give a better chance to GPE to >>>>>be >>>>> implemented, as vendors may want a cost effective way to migrate to >>>>>the >>>>> new protocol while preserving compatibility with legacy >>>>>implementations. >>>>> >>>>> The fact that GPE provides a way to be extended, either with a shim >>>>> a-la NSH or making availabe more bits in the header for future >>>>> features, I think opens up to the addition of new features (explicit >>>>> service tagging, as an example) in a more organic way than trying to >>>>> use the few bits left in VXLAN or LISP. >>>>> >>>>> Unfortunately, in the LISP case, this comes to the expense of some >>>>> features that are in the current specification, but I believe those >>>>> same features can be mapped on a GPE+shim header, so a new >>>>> implementation would be able to provide the equivalent of those >>>>> features (e.g. nonce). >>>>> >>>>> It's hard to find the right balance between backward compatibility >>>>>and >>>>> evolution of the encapsulation, but I believe GPE gets to a decent >>>>> compromise. >>>>> >>>>> Thanks, >>>>> Fabio >>>>> >>>>> >>>>> >>>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>>>> Hi VXLAN-gpe authors, >>>>>>>> >>>>>>>> Abstract: technically this is not extending a VXLAN but defines a >>>>>>>> new protocol that looks similar to VXLAN (demonstrated by need for >>>>>>>> new UDP port assignment). >>>>>>> We are trying to balance re-use of the VXLAN format and the need to >>>>>>> support existing non-GPE hardware that might already be deployed. >>>>>>>We >>>>>>> looked at using the same port, and the new one, and decided, at >>>>>>>this >>>>>>> point that a new port is easier for migration but since the packet >>>>>>> format is essentially VXLAN to keep the VXLAN name. >>>>>> Paul, this design seems to be going in circles. If a new port is >>>>>> used, why not make the new port for VXLAN mean layer-3 protocols >>>>>> follow? Or better yet, have a demux field after the VXLAN header so >>>>>> you don't have to use VXLAN header bits. Because the P-bit is using >>>>>>a >>>>>> precious bit in the VXLAN/LISP header and the nonce field that can >>>>>>be >>>>>> used for other things (we have history that shows a nonce in the >>>>>> header is a cheap form of obscure security). >>>>>> >>>>>> If you do this then you have no compatibility problems with initial >>>>>> VXLAN and LISP implementations. >>>>>> >>>>>> And, most importantly, there will be less confusion in the >>>>>> marketplace. >>>>>> >>>>>> Dino >>>>>> _______________________________________________ >>>>>> nvo3 mailing list >>>>>> nvo3@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 > From nobody Fri Jul 18 10:00:23 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9CB1A01C8 for ; Fri, 18 Jul 2014 10:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 XNit4GJDyv4l for ; Fri, 18 Jul 2014 10:00:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FA71B2797 for ; Fri, 18 Jul 2014 10:00:11 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so8028185vcb.3 for ; Fri, 18 Jul 2014 10:00:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GAUm7u5KXtbVG2kOGPrFLmfCQiLto7Go2sRohYl1PgA=; b=gevyg1LXF9VkV3OgfVq1CfTfu+ZTFRrN2IxWKJqqJcMt7LgF30VjZl3cBqkquOKyPy 1YMTfSNdiyu1FYDG5a7+RBolSFKqf9cKVVlzSCSate89x+I9fPQ9d5QAwOcUeC2PSTrp CsCx8zpJN7Zx9Nxs6ZwOgZexFTZfxLzSn5SwoCvHqIgxL9A9sgbZL3FzpCMIOUuGzNlK kQTxoBg9Uy7RR6j8B63jBzDx19H6G50ItfgG2ZZgb9H4agTXtMQnRDNLisBDxg6ZweEN YWv5ku51sBgreHoNAQsAHzDDk7EWHAdnbkWmpIV6ZGLlcIjX4GiZRV5mQUCNyIPjMMns OYTQ== X-Gm-Message-State: ALoCoQm5uVyJyPY9ZqOt2cJqMI2RHFiJ4dEp4w9RrSJ8xOjC4UqzWa8XdrQAT03JjK98QGKog/pV X-Received: by 10.221.56.5 with SMTP id wa5mr4225748vcb.25.1405702810658; Fri, 18 Jul 2014 10:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Fri, 18 Jul 2014 09:59:50 -0700 (PDT) From: Jamal Hadi Salim Date: Fri, 18 Jul 2014 12:59:50 -0400 Message-ID: To: "forces@ietf.org" , "sdn@irtf.org" , nfvrg@irtf.org, vnfpool@ietf.org, nvo3@ietf.org, "i2rs@ietf.org" , sfc Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/o5xmZLdiJ7eCdRkHNKlH0_07Hlg Subject: [nvo3] BitsnBites ForCES PoC X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:00:15 -0000 Folks, I am sorry for spamming all these lists. You are being spammed because you are a cousin of ForCES. We are planning to have a ForCES based NFV/SDN PoC demonstration at the Bits and Bites event on Thursday night (1845-2100 at the Concert Hall). Given it is very hard to give a lot of details in the demo, Evangelos Haleplidis will present more details at the ForCES meeting Monday 15:20 at the Manitoba room. The official blurb is as follows: ------ SANA will demonstrate the proof-of-concept of the applicability of IETF's ForCES framework for both NFV management and SDN control. The ForCES data model will be utilized to describe VNFs, services and the infrastructure definition in a clear, formal and concise approach. The protocol will illustrate SDN control and NFV management of all modelled elements. The setup includes various NFV/SDN entities controlled and managed by the ForCES architecture execute under a singular simple programmatic API regardless of whether they are virtual or physical. The separation of hardware and software is illustrated by the same NF LFB data models implemented in: a)KVM virtual machines, b) Linux containers, c) linux kernel proper and d) ASIC based L2/3 (Broadcom chipset) in white box switches all working in unison. Infrastructure orchestration includes instantiating VMs, containers, applications and setup of basic network connectivity using appropriate ForCES LFBs. Service orchestration is again modelled by ForCES LFBs and both control and management activities for the services are driven by the ForCES protocol. We will illustrate 3GPP S/PGW simple connectivity (NAT-based) service and the advantages gained from (SDN) separating the datapath components of S/PGW from the control as well as (NFV) separation of hardware from software. This PoC is further illustrated in: http://nfvwiki.etsi.org/index.php?title=ForCES_Applicability_for_NFV_and_integrated_SDN -------- Apologies again for the mass email. cheers, jamal From nobody Fri Jul 18 11:21:15 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17481A00EC; Fri, 18 Jul 2014 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YJ3nMPABJmSY; Fri, 18 Jul 2014 11:21:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806F61A0091; Fri, 18 Jul 2014 11:21:09 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 18 Jul 2014 18:21:07 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0990.007; Fri, 18 Jul 2014 18:21:07 +0000 From: John E Drake To: Jamal Hadi Salim Thread-Topic: [sfc] BitsnBites ForCES PoC Thread-Index: AQHPoqnB/0IwhlC/pky+GbkxV4TKYpumJMEQ Date: Fri, 18 Jul 2014 18:21:06 +0000 Message-ID: <5B1198B1-1EBF-40D6-BDE7-31A2AD498636@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.100.47] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(189002)(199002)(51704005)(24454002)(92726001)(83322001)(106116001)(74502001)(80022001)(79102001)(36756003)(101416001)(77982001)(110136001)(106356001)(19580395003)(19580405001)(16799955002)(81342001)(99396002)(82746002)(46102001)(15202345003)(87936001)(81542001)(50986999)(64706001)(76176999)(95666004)(54356999)(85852003)(99286002)(86362001)(15188155005)(83716003)(21056001)(74662001)(92566001)(76482001)(33656002)(31966008)(2656002)(15975445006)(4396001)(20776003)(83072002)(85306003)(105586002)(66066001)(107046002)(104396001)(19623215001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/uCc3BouWET8Ubd8qucOZidp0-2M Cc: "vnfpool@ietf.org" , "i2rs@ietf.org" , "sdn@irtf.org" , sfc , "nvo3@ietf.org" , "nfvrg@irtf.org" , "forces@ietf.org" Subject: Re: [nvo3] [sfc] BitsnBites ForCES PoC X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 18:21:11 -0000 Shameless self-aggrandizement=20 Sent from my iPhone > On Jul 18, 2014, at 1:00 PM, "Jamal Hadi Salim" wrote= : >=20 > Folks, >=20 > I am sorry for spamming all these lists. You are being spammed because > you are a cousin of ForCES. >=20 > We are planning to have a ForCES based NFV/SDN PoC demonstration at the > Bits and Bites event on Thursday night (1845-2100 at the Concert Hall). > Given it is very hard to give a lot of details in the demo, Evangelos Hal= eplidis > will present more details at the ForCES meeting Monday 15:20 at the > Manitoba room. >=20 > The official blurb is as follows: > ------ > SANA will demonstrate the proof-of-concept of the applicability of > IETF's ForCES framework for both NFV management and SDN control. > The ForCES data model will be utilized to describe VNFs, services and the > infrastructure definition in a clear, formal and concise approach. > The protocol will illustrate SDN control and NFV management of all > modelled elements. >=20 > The setup includes various NFV/SDN entities controlled and managed by the > ForCES architecture execute under a singular simple programmatic API > regardless of whether they are virtual or physical. The > separation of hardware and software is illustrated by the same NF > LFB data models implemented in: > a)KVM virtual machines, b) Linux containers, c) linux kernel proper > and d) ASIC based L2/3 (Broadcom chipset) in white box switches > all working in unison. >=20 > Infrastructure orchestration includes instantiating VMs, containers, > applications and setup of basic network connectivity using appropriate > ForCES LFBs. > Service orchestration is again modelled by ForCES LFBs and > both control and management activities for the services are driven by > the ForCES protocol. >=20 > We will illustrate 3GPP S/PGW simple connectivity (NAT-based) service > and the advantages > gained from (SDN) separating the datapath components of S/PGW from the co= ntrol > as well as (NFV) separation of hardware from software. >=20 > This PoC is further illustrated in: > http://nfvwiki.etsi.org/index.php?title=3DForCES_Applicability_for_NFV_an= d_integrated_SDN > -------- >=20 > Apologies again for the mass email. >=20 > cheers, > jamal >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 18 15:17:12 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367751A02E6 for ; Fri, 18 Jul 2014 15:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7u6HHP7bDUW3 for ; Fri, 18 Jul 2014 15:16:58 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC621A02A3 for ; Fri, 18 Jul 2014 15:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7671; q=dns/txt; s=iport; t=1405721805; x=1406931405; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ECRGBLvtpGfuvGWp8XWoQvEWqF7tzp4xvm7pzc71sl8=; b=Naeys2gMhO8lu8+S3BkPNTCwex9xnLES6Hub69T6+GFGoQWCVemle3E0 JM4Su8bAVW4SpPl4QAm73o0QWzFNt5gOhrby9uCsvJb+uk1iHZ2DwwAEG fxzdxfJwSNDIiZ9Om64cD8tTmSGAfPlMbNam9JSl5FBux22vUZ4B5cHfI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAIGcyVOtJV2Y/2dsb2JhbABWA4MOUlcExHgKh0MBgQkWdoQDAQEBAwEBAQELLCsJCwwEAgEIEQQBAQEeCQchBgsUCQgCBA4FiC4DCQgNqjWRLA2HIxeJfoMggh0QBwYLhDUFjkOKX4IDgU2MRoYcg0RsgUU X-IronPort-AV: E=Sophos;i="5.01,688,1400025600"; d="scan'208";a="62131705" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 18 Jul 2014 22:16:41 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6IMGfYk018624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 22:16:41 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.251]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 17:16:41 -0500 From: "Surendra Kumar (smkumar)" To: Dino Farinacci , "Elzur, Uri" Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPoIcypuycooyZeU6+Ypfto33MkZuihr2AgADujICAAC0cAIAAA9OAgAAKXgCAAAM4gIAClYCA Date: Fri, 18 Jul 2014 22:16:41 +0000 Message-ID: References: <2F5794B5-0725-4748-9B28-576C608243F7@gmail.com> <53C612E1.1050501@cisco.com> <43531654-45E9-4C07-8863-1FE6AE623F65@gmail.com> <53C700D4.9060108@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453C04C1@dfweml701-chm.china.huawei.com> <7E05C330D7FD6D4FAD0728C46B899585819BECE2@ORSMSX114.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.89.95] Content-Type: text/plain; charset="us-ascii" Content-ID: <081C8CDC9CB15B4F94FBAA57658B3D4A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/pEeet4ZE-rthuFGyY-RPTUBQR9A Cc: "Fabio Maino \(fmaino\)" , "nvo3@ietf.org" , Lucy Yong Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 22:17:04 -0000 On 7/16/14 4:49 PM, "Dino Farinacci" wrote: >> VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC >>provides guidance for. I.e. given the anticipated interpretations, with >>proper scrutiny of what is allowed , VXLAN-gpe is attempting to allow >>for best backwards interoperability on the existing UDP 4789 and offer >>best prospects for carrying the additional headers/metadata. This leads >>to the need for new UDP port for new formats > >But for what features? > >If chips can change to support L3 overlays with VXLAN, which they will >have to do L3 header parsing as well as doing L3 lookups during >recirculation, then they could just end of doing LISP. Note, the LISP >header is exactly the same as the VXLAN header so the effort is the same. >Therefore there is no point in having a P-bit and a next-header field. > >As for NSH, it SHOULD have its own UDP header because you may want to use >it natively and NOT encapsulate. SK> Native use over UDP is part of NSH design. Surendra. > >Again, people will find that all the parameters in NSH are really not >necessary and just creates more things the network adminstrator has to >manage and track. A service will be defined by a 5-tuple and in many >cases, all packets may have to travel across a service chain. > >Dino > >>=20 >> Thx >> =20 >> Uri ("Oo-Ree") >> C: (949)-378-7568 >>=20 >>=20 >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >> Sent: Wednesday, July 16, 2014 4:00 PM >> To: Fabio Maino; Dino Farinacci >> Cc: nvo3@ietf.org >> Subject: Re: [nvo3] Comments on >>http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>=20 >> If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is >>a new protocol, why it has to align with VXLAN format? >>=20 >> Lucy >>=20 >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fabio Maino >> Sent: Wednesday, July 16, 2014 5:47 PM >> To: Dino Farinacci >> Cc: nvo3@ietf.org >> Subject: Re: [nvo3] Comments on >>http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>=20 >> Dino, >> GPE is not changing VXLAN nor LISP, as today's implementations cannot >>be changed. GPE is proposing a converged extension of both protocols >>that add some new features that, I believe, are needed. >>=20 >> All of VXLAN features are supported in GPE. >>=20 >> In the case of LISP, unfortunately, two features (nonce and >> map-versioning) could not be accommodated in GPE. This is not very >>different than any of today's LISP implementations that may decide to >>not support those two features (for whatever reason: cost, complexity, >>use cases addressed by the implementation... independently from GPE). >>=20 >> What GPE is trying to do is to simplify next generation implementations >>by keeping GPE as close as possible to the existing encapsulations, >>adding on top of those. I maintain that an implementation supporting >>GPE, LISP and VXLAN will be more cost effective than one that supports >>VXLAN, LISP and a clean slate protocol, and may have better chances of >>being deployed. >>=20 >> Fabio >>=20 >>=20 >> On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>> Well, if you want to really care about customers, creating all these >>>variations is not doing justice to them. If you want less combinations, >>>you keep VXLAN the way it is right now, with no changes. You keep LISP >>>the way it is right now with no changes. You get L2 and L3 overlays >>>with a unified pull control-plane in draft-maino-nv03-lisp-cp >>>(preaching to the author ;-) or use BGP as an alternative push >>>control-plane. >>>=20 >>> As for NSH, you create a new header because it is completely new >>>requirement and has not be deployed anywhere. Since it is brand new, >>>you need new hardware and code to be developed to support it. So >>>changing VXLAN and LISP to support NSH doesn't make sense because you >>>inject change in 3 places rather than in 1 new place, creating more >>>protocol machinery, complexity, and combinations that will frustrate >>>customers (not to mention vendor call centers). >>>=20 >>> Less entropy please, >>> Dino >>>=20 >>> On Jul 15, 2014, at 10:51 PM, Fabio Maino wrote: >>>=20 >>>> Dino, >>>> I believe that using a format that can share as much as possible with >>>>the two protocols deployed today will give a better chance to GPE to >>>>be implemented, as vendors may want a cost effective way to migrate to >>>>the new protocol while preserving compatibility with legacy >>>>implementations. >>>>=20 >>>> The fact that GPE provides a way to be extended, either with a shim >>>>a-la NSH or making availabe more bits in the header for future >>>>features, I think opens up to the addition of new features (explicit >>>>service tagging, as an example) in a more organic way than trying to >>>>use the few bits left in VXLAN or LISP. >>>>=20 >>>> Unfortunately, in the LISP case, this comes to the expense of some >>>>features that are in the current specification, but I believe those >>>>same features can be mapped on a GPE+shim header, so a new >>>>implementation would be able to provide the equivalent of those >>>>features (e.g. nonce). >>>>=20 >>>> It's hard to find the right balance between backward compatibility >>>>and evolution of the encapsulation, but I believe GPE gets to a decent >>>>compromise. >>>>=20 >>>> Thanks, >>>> Fabio >>>>=20 >>>>=20 >>>>=20 >>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>>>>> Hi VXLAN-gpe authors, >>>>>>>=20 >>>>>>> Abstract: technically this is not extending a VXLAN but defines a >>>>>>> new protocol that looks similar to VXLAN (demonstrated by need for >>>>>>> new UDP port assignment). >>>>>> We are trying to balance re-use of the VXLAN format and the need to >>>>>>support existing non-GPE hardware that might already be deployed. >>>>>>We looked at using the same port, and the new one, and decided, at >>>>>>this point that a new port is easier for migration but since the >>>>>>packet format is essentially VXLAN to keep the VXLAN name. >>>>> Paul, this design seems to be going in circles. If a new port is >>>>>used, why not make the new port for VXLAN mean layer-3 protocols >>>>>follow? Or better yet, have a demux field after the VXLAN header so >>>>>you don't have to use VXLAN header bits. Because the P-bit is using a >>>>>precious bit in the VXLAN/LISP header and the nonce field that can be >>>>>used for other things (we have history that shows a nonce in the >>>>>header is a cheap form of obscure security). >>>>>=20 >>>>> If you do this then you have no compatibility problems with initial >>>>>VXLAN and LISP implementations. >>>>>=20 >>>>> And, most importantly, there will be less confusion in the >>>>>marketplace. >>>>>=20 >>>>> Dino >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From nobody Mon Jul 21 06:35:06 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4B51B2E23 for ; Mon, 21 Jul 2014 06:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 UbRWu5pkhQ3E for ; Mon, 21 Jul 2014 06:34:59 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CBF1B2E18 for ; Mon, 21 Jul 2014 06:30:41 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so7487721wes.8 for ; Mon, 21 Jul 2014 06:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wy3mjWUkI3QwDS2sHwzUWnqjZPPPuDyU4WPvBKk7FyQ=; b=itVPDotLhBS++ZlpI4AyLQp/+w2DVdn4+wnAbnDA8lIFTada/kGgWQkYRtsIlXvLlJ e+VxK5Q4V+4ZqfGDrCkOaQCIBslKrMaB2xibnuK62UwEroKkEdqNRfqnWK+Y4kJMIJeJ cAIgoYpv4FFNdkgcG+N2kHQf0fORiHYvy/aTJKUCwmVoSiB9EZaGgY+D0b3nUJ4GC7HV AetqMGEv7UugDRjN1kmWDZE7g6WHFuWCahHa8EFjoKnok1MOlb5oiB9RdEYRRKs6jFgo DVv80Os4rHJUh9jpKoUNkpe3D1WGrftiQtZmZcwHk5gO2wTPTSoMe/j5QyGcP2Qm5Ce4 OIjA== X-Received: by 10.180.92.73 with SMTP id ck9mr4570658wib.54.1405949439549; Mon, 21 Jul 2014 06:30:39 -0700 (PDT) Received: from dhcp-a591.meeting.ietf.org (dhcp-a591.meeting.ietf.org. [31.133.165.145]) by mx.google.com with ESMTPSA id w5sm42074117wif.3.2014.07.21.06.30.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 06:30:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Sam K. Aldrin" In-Reply-To: Date: Mon, 21 Jul 2014 06:30:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: nvo3@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/wwkxmR1GMD9bfr-xMZn9LQfNvTc Cc: Benson Schliesser , "Bocci, Matthew \(Matthew\)" Subject: Re: [nvo3] Draft Agenda of IETF90 WG session X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:35:01 -0000 Presenters of NVo3 WG session, please send in your slides, if you = haven't done it yet, by today evening. cheers -sam On Jul 16, 2014, at 12:07 AM, Sam Aldrin wrote: > Hi, >=20 > Draft Agenda is now posted. >=20 > () >=20 > All presenters, please send in your presentations no later than 21st = July i.e. Monday EOB. > Please unicast it to me and cc WG chairs. >=20 > If there are any mistakes or corrections needed to the Agenda, please = let us know. > Final agenda and the order may change as we get closer to the meeting. >=20 > cheers > -sam From nobody Thu Jul 24 10:45:26 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB061A0547 for ; Thu, 24 Jul 2014 08:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 d7h0GDfuh99H for ; Thu, 24 Jul 2014 08:19:14 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FCC1A03D4 for ; Thu, 24 Jul 2014 08:16:16 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so2822199wes.8 for ; Thu, 24 Jul 2014 08:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=zyj52R/mU9S0rISuLU/aXdcyDkd78S2+5mtJ01u9GMg=; b=C3KId4MTt0OE/590G4fOl8xVRNmLJItvyDFmQDjyCuaBmXgCyTOqeiPRfAFZPtSaar FfSZlzs12v3MHLgOnst1tswZ5MMRQIBXE+Hm+1vkNpnxUtP7IjinoNUTq5pt9lW9WHWf 5fY+ZuJAEKKTltQ5ytpes0ZvjHL22YwkQXMS0gV4Nqux1B+az48RpyTZ6wcRzvxoSFQG agtomv5iB8onI1V/1zCSduxPGG57jkbxFc7YkiIY+p9gJmpR0mm4uEpNhoKG4Bw8CADd 32jpEavpiKec8slN1tJfoU6fhsRt+36HsNYto/DNOx0CUnX5pMCtvjqhyyVu78UQmA6U jGEA== X-Received: by 10.194.109.71 with SMTP id hq7mr13580064wjb.114.1406214974493; Thu, 24 Jul 2014 08:16:14 -0700 (PDT) Received: from [31.133.163.45] (dhcp-a32d.meeting.ietf.org. [31.133.163.45]) by mx.google.com with ESMTPSA id au7sm16640468wjc.41.2014.07.24.08.16.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 08:16:12 -0700 (PDT) From: Eric Gray Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11D257) Message-Id: Date: Thu, 24 Jul 2014 11:16:10 -0400 To: nvo3@ietf.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/5SZg2JhP4cfsZ8QfJ0r7ZxGPyhk X-Mailman-Approved-At: Thu, 24 Jul 2014 10:45:16 -0700 Subject: [nvo3] Presentation on Application Specific Multicast X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:19:20 -0000 I found the first bullet on the last slide shown during the presentation confusing. I seemed to be saying that the content of the draft does not fit in the NVo3 Architecture so the draft should be a stand alone draft. Does this mean it should become an "Application-Specific Multicast Architecture' draft (Linda said no on this question, asked during the presentation) Does it mean that the architecture draft needs to be extended so that this work will fit in the architecture? Or are we saying this work should be pursued in this working group, even though it does not fit the architecture (this makes little sense, and less)? -- Eric Sent from my iPad From nobody Thu Jul 24 11:22:41 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F2A1B27CD for ; Thu, 24 Jul 2014 11:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 hD3pQg7QQnIw for ; Thu, 24 Jul 2014 11:22:34 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B901B27B5 for ; Thu, 24 Jul 2014 11:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2945; q=dns/txt; s=iport; t=1406226154; x=1407435754; h=from:to:subject:date:message-id:mime-version; bh=0DTZX3whVVBbEDxbbZLGYB3mIFMG7t0kbhYzn95Xcj4=; b=OILFwEqP+uymsV8b+P17vFEk6L0WR3KxrXYSoD1obiUdLTTaT0LYI2Mh bYtiRRPTeejCM2Js8k1v0YFs9wNt+T1fN2B3C15PPvHLmn6QbrNiIUJyj RBxPXO0ONfO2oRDCIbvQOJjNkefECkjJUl62ly1ETGP5Fw+7V/I9zcZYw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGlN0VOtJV2Q/2dsb2JhbABYgkdHUlvQewGBDRZ3hAUBBC1eAQweViYBBBuIOphSpmsXjxqDZoEYBY5LoTCDSIIx X-IronPort-AV: E=Sophos; i="5.01,725,1400025600"; d="scan'208,217"; a="63763163" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP; 24 Jul 2014 18:22:33 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6OIMXlR025386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 18:22:33 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.9]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 13:22:33 -0500 From: "Joe Pelissier (jopeliss)" To: "nvo3@ietf.org" Thread-Topic: Comment on draft-gu-nvo3-virt-edge-auto-discovery Thread-Index: Ac+nbD7uK5ipjM78RAOy99IqOdPuTA== Date: Thu, 24 Jul 2014 18:22:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.144.186] Content-Type: multipart/alternative; boundary="_000_D1BA4C505C4FB0478FEE54F99BBB3C8D668F9EFDxmbalnx15ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/vkB8W85cluENvKwcgjc-je9Tp9U Subject: [nvo3] Comment on draft-gu-nvo3-virt-edge-auto-discovery X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:22:38 -0000 --_000_D1BA4C505C4FB0478FEE54F99BBB3C8D668F9EFDxmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings: It appears that the protocol introduced in draft-gu-nvo3-virt-edge-auto-dis= covery largely duplicates the work that was done in IEEE with VDP. I would= like to solicit the authors' view of potentially using VDP for this purpos= e. Thanks! Joe Pelissier --_000_D1BA4C505C4FB0478FEE54F99BBB3C8D668F9EFDxmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings:

It appears that the= protocol introduced in draft-gu-nvo3-virt-edge-auto-discovery largely dupl= icates the work that was done in IEEE with VDP.  I would like to solic= it the authors’ view of potentially using VDP for this purpose.

 

Thanks!<= /span>

Joe Pelissier<= /o:p>

--_000_D1BA4C505C4FB0478FEE54F99BBB3C8D668F9EFDxmbalnx15ciscoc_-- From nobody Thu Jul 24 13:02:15 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562DC1A0AC7 for ; Thu, 24 Jul 2014 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 FPNZMkiLQPDD for ; Thu, 24 Jul 2014 13:02:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448F41A01E8 for ; Thu, 24 Jul 2014 13:02:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKM54434; Thu, 24 Jul 2014 20:02:08 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 21:02:07 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 13:02:03 -0700 From: Linda Dunbar To: Eric Gray , "nvo3@ietf.org" Thread-Topic: [nvo3] Presentation on Application Specific Multicast Thread-Index: AQHPp2cVTcO+YdT79kOxzCkdblhSSJuvi0fQ Date: Thu, 24 Jul 2014 20:02:03 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DA5747@dfweml701-chm.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/S0-aDT46PfGYAv1SoZMIqxMNoc0 Subject: Re: [nvo3] Presentation on Application Specific Multicast X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:02:13 -0000 Eric,=20 Answers and clarification are inserted below: -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, July 24, 2014 10:16 AM To: nvo3@ietf.org Subject: [nvo3] Presentation on Application Specific Multicast I found the first bullet on the last slide shown during the presentation co= nfusing. I seemed to be saying that the content of the draft does not fit in the NVo3 Architecture so the draft should be a stand alone draft. [Linda] I mean to say that the content of this draft is substantial enough = to be an independent draft, instead of merging with "nvo3 arch" draft.=20 Does this mean it should become an "Application-Specific Multicast Architec= ture' draft (Linda said no on this question, asked during the presentation) [Linda] I mean to say that this draft is to layout the framework of various= schemes to tackle application specific multicast in overlay environment. T= alked to Dino after the NVo3 session, he mentioned that there are more to b= e added to the draft. He agreed to add more to the draft.=20 So this draft provides supplement material to "nvo3 framework" draft.=20 Does it mean that the architecture draft needs to be extended so that this = work will fit in the architecture? Or are we saying this work should be pursued in this working group, even th= ough it does not fit the architecture (this makes little sense, and less)? [Linda] The draft is for making the "Framework document" deliverable of cur= rent NVO3 charter more complete.=20 Cheers,=20 Linda -- Eric Sent from my iPad _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From nobody Thu Jul 24 16:48:31 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EAC1A0648 for ; Thu, 24 Jul 2014 16:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 j5_6lt9tnHqc for ; Thu, 24 Jul 2014 16:48:27 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0311A0537 for ; Thu, 24 Jul 2014 16:48:26 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so3537404wes.34 for ; Thu, 24 Jul 2014 16:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VyLsWYAJCFNvcrdoq0buhcBrp0x4mzBtUvh8GqMvDik=; b=PHMyr/gBWLBU9yr+NRTBaj5yy4Qoib5oau8pG3il1iN3dRYGQb/I2l2Y9C0WwWvRHb kma4RV0iBP8dV1kbac0qtcGAeYgudvvPnE13KmUzGZinHn0QhZb5H1JJVoupvlS7N6hw uevpKL21mO/guxq4u19blMa+Iy8JcYzGKZo+hew8WPAHrB7TRL14kfRCLEiFLMTjbbjI nRyMeRFB8Op2/QBgIDrmXSxyyg++BEXuh7pKIXTMNN10T6tW+JfsiR28cvE0mZDvOWQh VrU+yHZnCzfYZ0WquEUmY/qeIcZ4I+VvAcSa6Vyy1mzlo1vBzdCMOGI3HUsprbOyDxNH NZ+w== MIME-Version: 1.0 X-Received: by 10.180.19.200 with SMTP id h8mr656871wie.32.1406245705736; Thu, 24 Jul 2014 16:48:25 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.8.197 with HTTP; Thu, 24 Jul 2014 16:48:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Jul 2014 16:48:25 -0700 X-Google-Sender-Auth: ZiydK-1D7W01PvHQoIZ7WYsTlEk Message-ID: From: Anoop Ghanwani To: "Joe Pelissier (jopeliss)" Content-Type: multipart/alternative; boundary=bcaec53d5eb7c1e90504fef91759 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/03wNJlzCmtIwfiw7VYLhnEyG29k Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comment on draft-gu-nvo3-virt-edge-auto-discovery X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:48:29 -0000 --bcaec53d5eb7c1e90504fef91759 Content-Type: text/plain; charset=ISO-8859-1 I had the same comment/concern after listening to the presentation. One thing that I found significantly different from the VDP approach (which I am not sure that I can agree with as being the right approach, simply because it doesn't seem secure) is that, with this scheme, the VM directly discovers/registers with the NVE; in the case of the VDP approach, it is the hypervisor which does the registration. Anoop On Thu, Jul 24, 2014 at 11:22 AM, Joe Pelissier (jopeliss) < jopeliss@cisco.com> wrote: > Greetings: > > It appears that the protocol introduced in > draft-gu-nvo3-virt-edge-auto-discovery largely duplicates the work that was > done in IEEE with VDP. I would like to solicit the authors' view of > potentially using VDP for this purpose. > > > > Thanks! > > Joe Pelissier > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > --bcaec53d5eb7c1e90504fef91759 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I had the same comment/concern after listening to the pres= entation.

One thing that I found significantly different= from the VDP approach (which I am not sure that I can agree with as being = the right approach, simply because it doesn't seem secure) is that, wit= h this scheme, the VM directly discovers/registers with the NVE; in the cas= e of the VDP approach, it is the hypervisor which does the registration.

Anoop


On Thu, Jul 24, 2014 at 11:22 AM, Joe Pelissier (jo= peliss) <jopeliss@cisco.com> wrote:

Greetings:

It appears that the= protocol introduced in draft-gu-nvo3-virt-edge-auto-discovery largely dupl= icates the work that was done in IEEE with VDP.  I would like to solic= it the authors’ view of potentially using VDP for this purpose.

 

Thanks!

=

Joe Pelissier


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3


--bcaec53d5eb7c1e90504fef91759-- From nobody Thu Jul 24 16:57:39 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD861A04BA for ; Thu, 24 Jul 2014 16:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 S-6YaDGHWqR1 for ; Thu, 24 Jul 2014 16:57:34 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A8D1A0460 for ; Thu, 24 Jul 2014 16:57:34 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w61so3529902wes.39 for ; Thu, 24 Jul 2014 16:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=7baUpvREQ1X5q78cPjk2yco+baqi32jKVVyz26R2XL8=; b=MTT1bc2VMvoDpG6F8maOM9G1jwDVtuRg9bjcvEuA+GxNvs1W7YIqEyEHXkfqSSvPHg WwDcs4sdzogonuD+NRW/yJ36XEnWAj5QNlBfcc+s3gT5uCNmHVxG+Ac9IyWCoyHxSFyq QHRdnq/Odumc73sBD+3IuTk+yX1mGRu9ybM3dvvYa/DL36HVMptv9lp0Fc+vjINciN1H kJZT2u63sUcrgjjmFWd2p7CVlDhXR9bZzvqWkQi4BO+wVDXYisVKx3p1PaCHLquIPFAA 0s6Vf1unWcKrAlO7J0B6WaTtaEEREsemmiPCFx2/dsF7cEYvWFVERyf72fWqD5PUqlZ6 Clwg== MIME-Version: 1.0 X-Received: by 10.180.19.97 with SMTP id d1mr540815wie.19.1406246252992; Thu, 24 Jul 2014 16:57:32 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.8.197 with HTTP; Thu, 24 Jul 2014 16:57:32 -0700 (PDT) Date: Thu, 24 Jul 2014 16:57:32 -0700 X-Google-Sender-Auth: B1wsrfXntIkUikGSmyg1j3xpGLI Message-ID: From: Anoop Ghanwani To: "nvo3@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53f37df6062d504fef93802 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/D03xp84ivnXYMk8ZXbPwLaPBj_g Subject: [nvo3] user community concerned about lack of standards for network virtualization X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:57:37 -0000 --bcaec53f37df6062d504fef93802 Content-Type: text/plain; charset=ISO-8859-1 One of the comments I made at the mic in response to some of the WG reorganization statements was that the user community is complaining about lack of standards. The reference I would like to point folks to is the following whitepaper from ONUG: Unfortunately, there are too many different tunneling protocols and no multi-vendor interoperability between virtual overlay vendors. ... This ambiguity has caused the vendor community to create a number of disparate mechanisms for state distribution with very little or no interoperability such as OVSDB and a unicast approach to VXLAN tunnel creation while others are offering new protocols such as OpFlex, GENEVE, NVo3, MPLSoGRE, etc. ONUG is very concerned about this lack of interoperability and the implications it will have on next generation designs. You can get the document from here: http://opennetworkingusergroup.com/onug-white-paper/ Anoop --bcaec53f37df6062d504fef93802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

One of the comments I made at the mic = in response to some of the WG reorganization statements was that the user c= ommunity is complaining about lack of standards.

The reference I would like to point folks to is the following whitepaper fr= om ONUG:
<quote>
Unfortunately, there are to= o many different tunneling protocols
and no multi-vendor interope= rability between virtual overlay
vendors.
...
This ambiguity has caused the vendor = community to create a
number of disparate mechanisms for state di= stribution with
very little or no interoperability such as OVSDB = and a unicast
approach to VXLAN tunnel creation while others are offering
= new protocols such as OpFlex, GENEVE, NVo3, MPLSoGRE,
etc. ONUG i= s very concerned about this lack of interoperability
and the impl= ications it will have on next generation designs.
</quote>

You can get the document= from here:

Anoop
--bcaec53f37df6062d504fef93802-- From nobody Thu Jul 24 18:40:52 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCE51A0A86 for ; Thu, 24 Jul 2014 18:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 srMOpRn-VSMh for ; Thu, 24 Jul 2014 18:40:49 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E89D1A0944 for ; Thu, 24 Jul 2014 18:40:49 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id q9so2371081ykb.5 for ; Thu, 24 Jul 2014 18:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w7oqi7FW66Lhb9Q7du2AGsoBlOkdFp1r6s9MBevasAE=; b=s5y3copzQpGstgoMR6CqRZIo+QjZw1YnKgxGeXX/JqV8arjn1XlgHquUvTVl/YuTrm qABYec1gnmdOsnP4wCdHDe/TQKWkbh2jMHQrf/pSB4352j/fepZpXN6rvrfjc11/s4i7 zO0dFV6l3xf0JM6d4bNlBQ+zi0SdUC9XYEyjqwUPgrSdMVeROTJyX/WrIRHm5zETi/rn ofT590OpDFIdY9P9iUsu3hnBsqopPGNY/sZsdiS6KfniFy8wrcbAUszfiBtxeqH8ztc3 Xw5/Y3y4Oln/BsSJb90VgTo5qyrwW0KUxkVYoslLCeF1RMMUMGhSEPt1LqQI2aIXyPi2 wh+g== MIME-Version: 1.0 X-Received: by 10.236.137.242 with SMTP id y78mr17846541yhi.152.1406252448570; Thu, 24 Jul 2014 18:40:48 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Thu, 24 Jul 2014 18:40:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Jul 2014 21:40:48 -0400 Message-ID: From: Alia Atlas To: Anoop Ghanwani Content-Type: multipart/alternative; boundary=20cf303a2f8da9638304fefaa95c Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/LOWsVljcPYXd-VTXJNL53AIUcyE Cc: "nvo3@ietf.org" Subject: Re: [nvo3] user community concerned about lack of standards for network virtualization X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:40:51 -0000 --20cf303a2f8da9638304fefaa95c Content-Type: text/plain; charset=UTF-8 Anoop, Thanks for the pointer. I would certainly be delighted if NVO3 can quickly agree on and solidify a good solution or even, if need be, two (for experimental). Alia On Thu, Jul 24, 2014 at 7:57 PM, Anoop Ghanwani wrote: > > One of the comments I made at the mic in response to some of the WG > reorganization statements was that the user community is complaining about > lack of standards. > > The reference I would like to point folks to is the following whitepaper > from ONUG: > > Unfortunately, there are too many different tunneling protocols > and no multi-vendor interoperability between virtual overlay > vendors. > ... > This ambiguity has caused the vendor community to create a > number of disparate mechanisms for state distribution with > very little or no interoperability such as OVSDB and a unicast > approach to VXLAN tunnel creation while others are offering > new protocols such as OpFlex, GENEVE, NVo3, MPLSoGRE, > etc. ONUG is very concerned about this lack of interoperability > and the implications it will have on next generation designs. > > > You can get the document from here: > http://opennetworkingusergroup.com/onug-white-paper/ > > Anoop > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > --20cf303a2f8da9638304fefaa95c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Anoop,

Thanks for the pointer. =C2=A0I = would certainly be delighted if NVO3 can quickly
agree on and sol= idify a good solution or even, if need be, two (for experimental).

Alia


On Thu, Jul 24, 2014 at 7:57 PM, Anoop Ghanwani <anoop@a= lumni.duke.edu> wrote:

One of = the comments I made at the mic in response to some of the WG reorganization= statements was that the user community is complaining about lack of standa= rds.

The reference I would like to point folks to is the following whitepaper fr= om ONUG:
<quote>
Unfortunately, there are to= o many different tunneling protocols
and no multi-vendor interope= rability between virtual overlay
vendors.
...
This ambiguity has caused the vendor = community to create a
number of disparate mechanisms for state di= stribution with
very little or no interoperability such as OVSDB = and a unicast
approach to VXLAN tunnel creation while others are offering
= new protocols such as OpFlex, GENEVE, NVo3, MPLSoGRE,
etc. ONUG i= s very concerned about this lack of interoperability
and the impl= ications it will have on next generation designs.
</quote>

You can get the document= from here:

Anoop

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3


--20cf303a2f8da9638304fefaa95c-- From nobody Fri Jul 25 02:08:35 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C171A00FC for ; Fri, 25 Jul 2014 02:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 gjQ3K650xdCU for ; Fri, 25 Jul 2014 02:08:28 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5D71A008B for ; Fri, 25 Jul 2014 02:08:27 -0700 (PDT) Received: from DBXPR06MB399.eurprd06.prod.outlook.com (10.141.14.23) by DBXPR06MB400.eurprd06.prod.outlook.com (10.141.14.24) with Microsoft SMTP Server (TLS) id 15.0.985.8; Fri, 25 Jul 2014 09:08:25 +0000 Received: from DBXPR06MB399.eurprd06.prod.outlook.com ([10.141.14.23]) by DBXPR06MB399.eurprd06.prod.outlook.com ([10.141.14.23]) with mapi id 15.00.0985.008; Fri, 25 Jul 2014 09:08:24 +0000 From: Sharon Barkai To: Anoop Ghanwani Thread-Topic: [nvo3] user community concerned about lack of standards for network virtualization Thread-Index: AQHPp5sRs2A/G/1wQEKX8YI9xPA/6JuwgMQw Date: Fri, 25 Jul 2014 09:08:24 +0000 Message-ID: <3BCB0982-CFA2-4014-AEE9-F499F39564A6@Contextream.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:144:b9ba:e877:746f:385a] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(377454003)(189002)(24454002)(85852003)(106356001)(54356999)(64706001)(86362001)(19580395003)(15395725005)(92566001)(83072002)(80022001)(74502001)(20776003)(107046002)(79102001)(31966008)(77982001)(81342001)(92726001)(110136001)(19617315012)(105586002)(106116001)(76176999)(15975445006)(50986999)(82746002)(33656002)(19580405001)(2171001)(87936001)(21056001)(81542001)(99396002)(83716003)(83322001)(4396001)(15202345003)(36756003)(46102001)(2656002)(16236675004)(95666004)(101416001)(85306003)(76482001)(74662001)(104396001)(3826002)(80792004); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR06MB400; H:DBXPR06MB399.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_3BCB0982CFA24014AEE9F499F39564A6Contextreamcom_" MIME-Version: 1.0 X-OriginatorOrg: Contextream.com Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/beF1zfUDEE_L3jOl8Uhlixjze8E Cc: "nvo3@ietf.org" Subject: Re: [nvo3] user community concerned about lack of standards for network virtualization X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:08:32 -0000 --_000_3BCB0982CFA24014AEE9F499F39564A6Contextreamcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anoop, what you describe is very true and is must be a result of perceived = standardization vacuum. NVO3 is in a position to fix this because it is not already "in love" with = a specific information distribution mechanics - Rather it can phrase the NV= A information that needs to be globally available in a form of Schema, For example: given that all vendors use overlay tunnels, simply state in a = Schema, per given end point identity (IP or MAC), on which tunnel destinati= on IP is it. We can differ for later discussion the push, or on-demand pull= mechanics used to distribute this. At least it will be clear first what is= it we want to obtain in NVEs from the NVA. This adds to the mic discussion regarding the various Gateways people right= fully start to specify. Gateways which are special NVEs that lead out of th= e NVO. We can state the information Schema needed to support these gateways like t= heir IP, the protocols to the outside they support eg any-cast, bridging, B= GP, etc so the other NVEs can use them. Same goes for OEM KPI data stored b= y the NVA, populated and used by NVEs, orchestration etc. Once we have defined the above using which ever table language, we can exam= ine Schema comparability between all the solutions out there, in any case S= chema keeps evolving, And we also supplement push / pull mechanics for sett= ing / getting that data. At least we will know what it is we want to be kno= wn across the overlay, any overlay, using the underlay based NVA control. Together with encapsulation specs and selection - which can also be availab= le per NVE IP as a Schema, we can achieve vendor interoperability and base = for evolution eg NVEs which are Gateways, NVEs which are SFFs, NVEs which = are RTRs etc. Sorry for the long note - IETF jet lag:) --szb On Jul 24, 2014, at 7:57 PM, "Anoop Ghanwani" > wrote: One of the comments I made at the mic in response to some of the WG reorgan= ization statements was that the user community is complaining about lack of= standards. The reference I would like to point folks to is the following whitepaper fr= om ONUG: Unfortunately, there are too many different tunneling protocols and no multi-vendor interoperability between virtual overlay vendors. ... This ambiguity has caused the vendor community to create a number of disparate mechanisms for state distribution with very little or no interoperability such as OVSDB and a unicast approach to VXLAN tunnel creation while others are offering new protocols such as OpFlex, GENEVE, NVo3, MPLSoGRE, etc. ONUG is very concerned about this lack of interoperability and the implications it will have on next generation designs. You can get the document from here: http://opennetworkingusergroup.com/onug-white-paper/ Anoop _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_3BCB0982CFA24014AEE9F499F39564A6Contextreamcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Anoop, what you describe is very true and is must be a result of perce= ived standardization vacuum.

NVO3 is in a position to fix this because it is not already "in l= ove" with a specific information distribution mechanics - Rather it ca= n phrase the NVA information that needs to be globally available in a form = of Schema,

For example: given that all vendors use overlay tunnels, simply state = in a Schema, per given end point identity (IP or MAC), on which tunnel dest= ination IP is it. We can differ for later discussion the push, or on-demand= pull mechanics used to distribute this. At least it will be clear first what is it we want to obtain in NVEs= from the NVA.

This adds to the mic discussion regarding the various Gateways people = rightfully start to specify. Gateways which are special NVEs that lead out = of the NVO. 

We can state the information Schema needed to support these gateways l= ike their IP, the protocols to the outside they support eg any-cast, bridgi= ng, BGP, etc so the other NVEs can use them. Same goes for OEM KPI data sto= red by the NVA, populated and used by NVEs, orchestration etc.

Once we have defined the above using which ever table language, we can= examine Schema comparability between all the solutions out there, in any c= ase Schema keeps evolving, And we also supplement push / pull mechanics for= setting / getting that data. At least we will know what it is we want to be known across the overlay, any = overlay, using the underlay based NVA control.

Together with encapsulation specs and selection - which can also be av= ailable per NVE IP as a Schema, we can achieve vendor interoperability and = base for evolution eg NVEs which are Gateways,  NVEs which are SFFs, N= VEs which are RTRs etc.

Sorry for the long note - IETF jet lag:)

--szb

On Jul 24, 2014, at 7:57 PM, "Anoop Ghanwani" <anoop@alumni.duke.edu> wrote:


One of the comments I made at the mic in response to some of the WG re= organization statements was that the user community is complaining about la= ck of standards.

The reference I would like to point folks to is the following whitepap= er from ONUG:
<quote>
Unfortunately, there are too many different tunneling protocols
and no multi-vendor interoperability between virtual overlay
vendors.
...
This ambiguity has caused the vendor community to create a
number of disparate mechanisms for state distribution with
very little or no interoperability such as OVSDB and a unicast
approach to VXLAN tunnel creation while others are offering
new protocols such as OpFlex, GENEVE, NVo3, MPLSoGRE,
etc. ONUG is very concerned about this lack of interoperability
and the implications it will have on next generation designs.
</quote>

You can get the document from here:

Anoop
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ie= tf.org/mailman/listinfo/nvo3
--_000_3BCB0982CFA24014AEE9F499F39564A6Contextreamcom_-- From nobody Fri Jul 25 08:09:39 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107881A03B9; Fri, 25 Jul 2014 08:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.25 X-Spam-Level: X-Spam-Status: No, score=-93.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, USER_IN_WHITELIST=-100] autolearn=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 rpNUcXrh6ECd; Fri, 25 Jul 2014 08:09:30 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 11F061B2925; Fri, 25 Jul 2014 08:09:24 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 11F874A74; Fri, 25 Jul 2014 23:09:03 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 2B0A8CEC2B5; Fri, 25 Jul 2014 23:09:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s6PF9DCR079524; Fri, 25 Jul 2014 23:09:13 +0800 (GMT-8) (envelope-from gu.zhongyu@zte.com.cn) In-Reply-To: To: "Joe Pelissier (jopeliss)" MIME-Version: 1.0 X-KeepSent: A752F2CB:8DE3965C-48257D20:0052F66C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gu.zhongyu@zte.com.cn Date: Fri, 25 Jul 2014 23:08:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-25 23:09:06, Serialize complete at 2014-07-25 23:09:06 Content-Type: multipart/alternative; boundary="=_alternative 005325C548257D20_=" X-MAIL: mse01.zte.com.cn s6PF9DCR079524 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/-Dmy43zBgSxvZCOIKwhSgFME7JE Cc: "nvo3@ietf.org" , nvo3 Subject: [nvo3] =?gb2312?b?tPC4tDogIENvbW1lbnQgb24gZHJhZnQtZ3UtbnZvMy12?= =?gb2312?b?aXJ0LWVkZ2UtYXV0by1kaXNjb3Zlcnk=?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:09:36 -0000 This is a multipart message in MIME format. --=_alternative 005325C548257D20_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KVkRQIGFuZCBOVkUgYXV0by1kaXNj b3ZlcnkgYWxsIGNhbiBiZSB1c2VkIGFzIFZNLU5WRSBwcm90b2NvbCwgc28gDQpzb21ldGhpbmcg bG9va3MgbGlrZS4NCg0KQnV0IFZORSBhdXRvLWRpc2NvdmVyeSBoYXMgIHNvbWUgZGlmZmVyZW50 IGZlYXR1cmVzL2Z1bmN0aW9ucywgZm9yIA0KZXhhbXBsZSwgZ2V0IFZNKCdzIG5ldHdvcmsgcGFy YW1ldGVycykgY29uZmlndXJlZCBhdXRvbWF0aWNhbGx5LA0KZS5nLiB3aXRoIFZORSBhdXRvLWRp c2NvdmVyeSwgVk0gY2FuIG9idGFpbiBpdHMgSVAgYWRkcmVzcyBhbmQvb3IgVkxBTi1JRCANCmZy b20gTlZFL25ldHdvcmtzaWRlLg0KDQpUaGFua3MhDQoNClpob25neXUNCg0KDQoNCg0KDQoNCg0K DQoiSm9lIFBlbGlzc2llciAoam9wZWxpc3MpIiA8am9wZWxpc3NAY2lzY28uY29tPiANCreivP7I yzogICJudm8zIiA8bnZvMy1ib3VuY2VzQGlldGYub3JnPg0KMjAxNC0wNy0yNSAwMjoyMg0KDQrK 1bz+yMsNCiJudm8zQGlldGYub3JnIiA8bnZvM0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KW252 bzNdIENvbW1lbnQgb24gZHJhZnQtZ3UtbnZvMy12aXJ0LWVkZ2UtYXV0by1kaXNjb3ZlcnkNCg0K DQoNCg0KDQoNCkdyZWV0aW5nczoNCkl0IGFwcGVhcnMgdGhhdCB0aGUgcHJvdG9jb2wgaW50cm9k dWNlZCBpbiANCmRyYWZ0LWd1LW52bzMtdmlydC1lZGdlLWF1dG8tZGlzY292ZXJ5IGxhcmdlbHkg ZHVwbGljYXRlcyB0aGUgd29yayB0aGF0IA0Kd2FzIGRvbmUgaW4gSUVFRSB3aXRoIFZEUC4gIEkg d291bGQgbGlrZSB0byBzb2xpY2l0IHRoZSBhdXRob3Jzoa8gdmlldyBvZiANCnBvdGVudGlhbGx5 IHVzaW5nIFZEUCBmb3IgdGhpcyBwdXJwb3NlLg0KIA0KVGhhbmtzIQ0KSm9lIFBlbGlzc2llcl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpudm8zIG1haWxp bmcgbGlzdA0KbnZvM0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9udm8zDQoNCg0K --=_alternative 005325C548257D20_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRz LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VkRQIGFu ZCBOVkUgYXV0by1kaXNjb3ZlcnkgYWxsIGNhbiBiZQ0KdXNlZCBhcyBWTS1OVkUgcHJvdG9jb2ws IHNvIHNvbWV0aGluZyBsb29rcyBsaWtlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+QnV0IFZORSBhdXRvLWRpc2NvdmVyeSBoYXMgJm5ic3A7c29tZQ0K ZGlmZmVyZW50IGZlYXR1cmVzL2Z1bmN0aW9ucywgZm9yIGV4YW1wbGUsIGdldCBWTSgncyBuZXR3 b3JrIHBhcmFtZXRlcnMpDQpjb25maWd1cmVkIGF1dG9tYXRpY2FsbHksPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5lLmcuIHdpdGggVk5FIGF1dG8tZGlzY292ZXJ5 LCBWTSBjYW4NCm9idGFpbiBpdHMgSVAgYWRkcmVzcyBhbmQvb3IgVkxBTi1JRCBmcm9tIE5WRS9u ZXR3b3Jrc2lkZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlRoYW5rcyE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlpob25neXU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCjwvZm9udD4NCjx0YWJsZT4NCjx0cj4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0pvZSBQZWxp c3NpZXIgKGpvcGVsaXNzKSZxdW90Ow0KJmx0O2pvcGVsaXNzQGNpc2NvLmNvbSZndDs8L2I+IDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDsm cXVvdDtudm8zJnF1b3Q7ICZsdDtudm8zLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTQtMDctMjUgMDI6MjI8L2ZvbnQ+DQo8 dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bnZv M0BpZXRmLm9yZyZxdW90OyAmbHQ7bnZvM0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltudm8zXSBDb21tZW50IG9u IGRyYWZ0LWd1LW52bzMtdmlydC1lZGdlLWF1dG8tZGlzY292ZXJ5PC9mb250PjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkdyZWV0 aW5nczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkl0IGFwcGVhcnMg dGhhdCB0aGUgcHJvdG9jb2wgaW50cm9kdWNlZA0KaW4gZHJhZnQtZ3UtbnZvMy12aXJ0LWVkZ2Ut YXV0by1kaXNjb3ZlcnkgbGFyZ2VseSBkdXBsaWNhdGVzIHRoZSB3b3JrIHRoYXQNCndhcyBkb25l IGluIElFRUUgd2l0aCBWRFAuICZuYnNwO0kgd291bGQgbGlrZSB0byBzb2xpY2l0IHRoZSBhdXRo b3Jzoa8NCnZpZXcgb2YgcG90ZW50aWFsbHkgdXNpbmcgVkRQIGZvciB0aGlzIHB1cnBvc2UuPC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPlRoYW5rcyE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9IkNhbGlicmkiPkpvZSBQZWxpc3NpZXI8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm52bzMg bWFpbGluZyBsaXN0PGJyPg0KbnZvM0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbnZvMzxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 005325C548257D20_=-- From nobody Fri Jul 25 08:10:31 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1661B29BE; Fri, 25 Jul 2014 08:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.25 X-Spam-Level: X-Spam-Status: No, score=-93.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, USER_IN_WHITELIST=-100] autolearn=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 EoYbjus1JM7i; Fri, 25 Jul 2014 08:10:11 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2617B1B294D; Fri, 25 Jul 2014 08:10:08 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id C1EB74AA6; Fri, 25 Jul 2014 23:09:48 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 7A8C6769B66; Fri, 25 Jul 2014 23:09:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s6PF9tm7048927; Fri, 25 Jul 2014 23:09:55 +0800 (GMT-8) (envelope-from gu.zhongyu@zte.com.cn) In-Reply-To: MIME-Version: 1.0 To: "Joe Pelissier (jopeliss)" X-KeepSent: A752F2CB:8DE3965C-48257D20:0052F66C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gu.zhongyu@zte.com.cn Date: Fri, 25 Jul 2014 23:09:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-25 23:09:50, Serialize complete at 2014-07-25 23:09:50 Content-Type: multipart/alternative; boundary="=_alternative 00534B5648257D20_=" X-MAIL: mse02.zte.com.cn s6PF9tm7048927 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/N2iQK9mj5IbrLZ7pemMVWOhMRQY Cc: "nvo3@ietf.org" , nvo3 Subject: [nvo3] =?gb2312?b?tPC4tDogIENvbW1lbnQgb24gZHJhZnQtZ3UtbnZvMy12?= =?gb2312?b?aXJ0LWVkZ2UtYXV0by1kaXNjb3Zlcnk=?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:10:15 -0000 This is a multipart message in MIME format. --=_alternative 00534B5648257D20_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KVkRQIGFuZCBOVkUgYXV0by1kaXNj b3ZlcnkgYWxsIGNhbiBiZSB1c2VkIGFzIFZNLU5WRSBwcm90b2NvbCwgc28gDQpzb21ldGhpbmcg bG9va3MgbGlrZS4NCg0KQnV0IFZORSBhdXRvLWRpc2NvdmVyeSBoYXMgIHNvbWUgZGlmZmVyZW50 IGZlYXR1cmVzL2Z1bmN0aW9ucywgZm9yIA0KZXhhbXBsZSwgZ2V0IFZNKCdzIG5ldHdvcmsgcGFy YW1ldGVycykgY29uZmlndXJlZCBhdXRvbWF0aWNhbGx5LA0KZS5nLiB3aXRoIFZORSBhdXRvLWRp c2NvdmVyeSwgVk0gY2FuIG9idGFpbiBpdHMgSVAgYWRkcmVzcyBhbmQvb3IgVkxBTi1JRCANCmZy b20gTlZFL25ldHdvcmtzaWRlLg0KDQpUaGFua3MhDQoNClpob25neXUgR3UNCg0KDQoNCg0KDQoN Cg0KDQoiSm9lIFBlbGlzc2llciAoam9wZWxpc3MpIiA8am9wZWxpc3NAY2lzY28uY29tPiANCrei vP7IyzogICJudm8zIiA8bnZvMy1ib3VuY2VzQGlldGYub3JnPg0KMjAxNC0wNy0yNSAwMjoyMg0K DQrK1bz+yMsNCiJudm8zQGlldGYub3JnIiA8bnZvM0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0K W252bzNdIENvbW1lbnQgb24gZHJhZnQtZ3UtbnZvMy12aXJ0LWVkZ2UtYXV0by1kaXNjb3ZlcnkN Cg0KDQoNCg0KDQoNCkdyZWV0aW5nczoNCkl0IGFwcGVhcnMgdGhhdCB0aGUgcHJvdG9jb2wgaW50 cm9kdWNlZCBpbiANCmRyYWZ0LWd1LW52bzMtdmlydC1lZGdlLWF1dG8tZGlzY292ZXJ5IGxhcmdl bHkgZHVwbGljYXRlcyB0aGUgd29yayB0aGF0IA0Kd2FzIGRvbmUgaW4gSUVFRSB3aXRoIFZEUC4g IEkgd291bGQgbGlrZSB0byBzb2xpY2l0IHRoZSBhdXRob3Jzoa8gdmlldyBvZiANCnBvdGVudGlh bGx5IHVzaW5nIFZEUCBmb3IgdGhpcyBwdXJwb3NlLg0KIA0KVGhhbmtzIQ0KSm9lIFBlbGlzc2ll cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpudm8zIG1h aWxpbmcgbGlzdA0KbnZvM0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9udm8zDQoNCg0K --=_alternative 00534B5648257D20_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRz LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VkRQIGFu ZCBOVkUgYXV0by1kaXNjb3ZlcnkgYWxsIGNhbiBiZQ0KdXNlZCBhcyBWTS1OVkUgcHJvdG9jb2ws IHNvIHNvbWV0aGluZyBsb29rcyBsaWtlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+QnV0IFZORSBhdXRvLWRpc2NvdmVyeSBoYXMgJm5ic3A7c29tZQ0K ZGlmZmVyZW50IGZlYXR1cmVzL2Z1bmN0aW9ucywgZm9yIGV4YW1wbGUsIGdldCBWTSgncyBuZXR3 b3JrIHBhcmFtZXRlcnMpDQpjb25maWd1cmVkIGF1dG9tYXRpY2FsbHksPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5lLmcuIHdpdGggVk5FIGF1dG8tZGlzY292ZXJ5 LCBWTSBjYW4NCm9idGFpbiBpdHMgSVAgYWRkcmVzcyBhbmQvb3IgVkxBTi1JRCBmcm9tIE5WRS9u ZXR3b3Jrc2lkZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlRoYW5rcyE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlpob25neXUgR3U8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCjwvZm9udD4NCjx0YWJsZT4NCjx0cj4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0pvZSBQ ZWxpc3NpZXIgKGpvcGVsaXNzKSZxdW90Ow0KJmx0O2pvcGVsaXNzQGNpc2NvLmNvbSZndDs8L2I+ IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJz cDsmcXVvdDtudm8zJnF1b3Q7ICZsdDtudm8zLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTQtMDctMjUgMDI6MjI8L2ZvbnQ+ DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7 bnZvM0BpZXRmLm9yZyZxdW90OyAmbHQ7bnZvM0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltudm8zXSBDb21tZW50 IG9uIGRyYWZ0LWd1LW52bzMtdmlydC1lZGdlLWF1dG8tZGlzY292ZXJ5PC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkdy ZWV0aW5nczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkl0IGFwcGVh cnMgdGhhdCB0aGUgcHJvdG9jb2wgaW50cm9kdWNlZA0KaW4gZHJhZnQtZ3UtbnZvMy12aXJ0LWVk Z2UtYXV0by1kaXNjb3ZlcnkgbGFyZ2VseSBkdXBsaWNhdGVzIHRoZSB3b3JrIHRoYXQNCndhcyBk b25lIGluIElFRUUgd2l0aCBWRFAuICZuYnNwO0kgd291bGQgbGlrZSB0byBzb2xpY2l0IHRoZSBh dXRob3Jzoa8NCnZpZXcgb2YgcG90ZW50aWFsbHkgdXNpbmcgVkRQIGZvciB0aGlzIHB1cnBvc2Uu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPlRoYW5rcyE8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IkNhbGlicmkiPkpvZSBQZWxpc3NpZXI8L2ZvbnQ+PHR0Pjxmb250IHNpemU9 Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm52 bzMgbWFpbGluZyBsaXN0PGJyPg0KbnZvM0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbnZvMzxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 00534B5648257D20_=-- From nobody Fri Jul 25 08:33:53 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7991B2950; Fri, 25 Jul 2014 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.25 X-Spam-Level: X-Spam-Status: No, score=-95.25 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 nBWbRWRp_Hpk; Fri, 25 Jul 2014 08:33:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id F37621B291B; Fri, 25 Jul 2014 08:33:46 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id AE30A12A0DAE; Fri, 25 Jul 2014 23:33:27 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id B323F769D83; Fri, 25 Jul 2014 23:33:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s6PFXa7P078462; Fri, 25 Jul 2014 23:33:37 +0800 (GMT-8) (envelope-from gu.zhongyu@zte.com.cn) In-Reply-To: To: Anoop Ghanwani MIME-Version: 1.0 X-KeepSent: 99B862EA:C35B40D7-48257D20:0054632E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gu.zhongyu@zte.com.cn Date: Fri, 25 Jul 2014 23:32:52 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-25 23:33:31, Serialize complete at 2014-07-25 23:33:31 Content-Type: multipart/alternative; boundary="=_alternative 0055674848257D20_=" X-MAIL: mse02.zte.com.cn s6PFXa7P078462 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/eIR-0d83PVcG0PG7LX2pMkvJGzw Cc: "Joe Pelissier \(jopeliss\)" , "nvo3@ietf.org" , nvo3 Subject: [nvo3] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50IG9uIGRyYWZ0LWd1LW52?= =?gb2312?b?bzMtdmlydC1lZGdlLWF1dG8tZGlzY292ZXJ5?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:33:49 -0000 This is a multipart message in MIME format. --=_alternative 0055674848257D20_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 V2UgaGF2ZSB0aGUgc2FtZSBzZWN1cmUgY29uY2Vybi4NCg0KU28gdHlwaWNhbGx5IE5WRSBhdXRv LWRpc2NvdmVyeSBzaGFsbCBiZSB1c2VkIHdpdGggc29tZSBhdXRoZW50aWNhdGlvbiANCm1lYXN1 cmVzIGFuZCBpdCBvd25zIHNvbWUgc2VjdXJpdHkgc3VwcG9ydGluZyBmZWF0dXJlcywgZm9yIGV4 YW1wbGUgDQpTZXNzaW9uLUlEIGZpZWxkLg0KDQpQcmVzZW50YXRpb24gdGltZSBsaW1pdGVkLCBw bHMgcmVmZXIgdG8gdGhlIGRyYWZ0IGl0c2VsZiBmb3IgZnVydGhlciBpbmZvLg0KDQpUaGFua3Mh DQoNClpob25neXUNCg0KDQoNCg0KDQoNCg0KDQoNCkFub29wIEdoYW53YW5pIDxhbm9vcEBhbHVt bmkuZHVrZS5lZHU+IA0Kt6K8/sjLOiAgIm52bzMiIDxudm8zLWJvdW5jZXNAaWV0Zi5vcmc+DQoy MDE0LTA3LTI1IDA3OjQ4DQoNCsrVvP7Iyw0KIkpvZSBQZWxpc3NpZXIgKGpvcGVsaXNzKSIgPGpv cGVsaXNzQGNpc2NvLmNvbT4NCrOty80NCiJudm8zQGlldGYub3JnIiA8bnZvM0BpZXRmLm9yZz4N Ctb3zOINClJlOiBbbnZvM10gQ29tbWVudCBvbiBkcmFmdC1ndS1udm8zLXZpcnQtZWRnZS1hdXRv LWRpc2NvdmVyeQ0KDQoNCg0KDQoNCg0KSSBoYWQgdGhlIHNhbWUgY29tbWVudC9jb25jZXJuIGFm dGVyIGxpc3RlbmluZyB0byB0aGUgcHJlc2VudGF0aW9uLg0KDQpPbmUgdGhpbmcgdGhhdCBJIGZv dW5kIHNpZ25pZmljYW50bHkgZGlmZmVyZW50IGZyb20gdGhlIFZEUCBhcHByb2FjaCANCih3aGlj aCBJIGFtIG5vdCBzdXJlIHRoYXQgSSBjYW4gYWdyZWUgd2l0aCBhcyBiZWluZyB0aGUgcmlnaHQg YXBwcm9hY2gsIA0Kc2ltcGx5IGJlY2F1c2UgaXQgZG9lc24ndCBzZWVtIHNlY3VyZSkgaXMgdGhh dCwgd2l0aCB0aGlzIHNjaGVtZSwgdGhlIFZNIA0KZGlyZWN0bHkgZGlzY292ZXJzL3JlZ2lzdGVy cyB3aXRoIHRoZSBOVkU7IGluIHRoZSBjYXNlIG9mIHRoZSBWRFAgDQphcHByb2FjaCwgaXQgaXMg dGhlIGh5cGVydmlzb3Igd2hpY2ggZG9lcyB0aGUgcmVnaXN0cmF0aW9uLg0KDQpBbm9vcA0KDQoN Ck9uIFRodSwgSnVsIDI0LCAyMDE0IGF0IDExOjIyIEFNLCBKb2UgUGVsaXNzaWVyIChqb3BlbGlz cykgPA0Kam9wZWxpc3NAY2lzY28uY29tPiB3cm90ZToNCkdyZWV0aW5nczoNCkl0IGFwcGVhcnMg dGhhdCB0aGUgcHJvdG9jb2wgaW50cm9kdWNlZCBpbiANCmRyYWZ0LWd1LW52bzMtdmlydC1lZGdl LWF1dG8tZGlzY292ZXJ5IGxhcmdlbHkgZHVwbGljYXRlcyB0aGUgd29yayB0aGF0IA0Kd2FzIGRv bmUgaW4gSUVFRSB3aXRoIFZEUC4gIEkgd291bGQgbGlrZSB0byBzb2xpY2l0IHRoZSBhdXRob3Jz oa8gdmlldyBvZiANCnBvdGVudGlhbGx5IHVzaW5nIFZEUCBmb3IgdGhpcyBwdXJwb3NlLg0KIA0K VGhhbmtzIQ0KSm9lIFBlbGlzc2llcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbnZvMyBtYWlsaW5nIGxpc3QNCm52bzNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbnZvMyBtYWlsaW5nIGxpc3QNCm52bzNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0KDQoN Cg== --=_alternative 0055674848257D20_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlIGhhdmUgdGhlIHNhbWUgc2Vj dXJlIGNvbmNlcm4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5TbyB0eXBpY2FsbHkgTlZFIGF1dG8tZGlzY292ZXJ5IHNoYWxsDQpiZSB1c2VkIHdpdGgg c29tZSBhdXRoZW50aWNhdGlvbiBtZWFzdXJlcyBhbmQgaXQgb3ducyBzb21lIHNlY3VyaXR5IHN1 cHBvcnRpbmcNCmZlYXR1cmVzLCBmb3IgZXhhbXBsZSBTZXNzaW9uLUlEIGZpZWxkLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UHJlc2VudGF0aW9uIHRp bWUgbGltaXRlZCwgcGxzIHJlZmVyDQp0byB0aGUgZHJhZnQgaXRzZWxmIGZvciBmdXJ0aGVyIGlu Zm8uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFu a3MhPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5aaG9u Z3l1PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0z NiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkFub29wIEdoYW53YW5pICZsdDth bm9vcEBhbHVtbmkuZHVrZS5lZHUmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwOyZxdW90O252bzMmcXVvdDsgJmx0O252bzMt Ym91bmNlc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAxNC0wNy0yNSAwNzo0ODwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtKb2UgUGVsaXNzaWVyIChqb3BlbGlzcykmcXVv dDsNCiZsdDtqb3BlbGlzc0BjaXNjby5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvN PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtu dm8zQGlldGYub3JnJnF1b3Q7ICZsdDtudm8zQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+UmU6IFtudm8zXSBDb21tZW50IG9uIGRyYWZ0LWd1LW52bzMtdmlydC1lZGdlLWF1dG8tZGlz Y292ZXJ5PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zPkkgaGFkIHRoZSBzYW1lIGNvbW1lbnQvY29uY2VybiBhZnRlciBsaXN0ZW5pbmcgdG8gdGhl DQpwcmVzZW50YXRpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5PbmUgdGhpbmcg dGhhdCBJIGZvdW5kIHNpZ25pZmljYW50bHkgZGlmZmVyZW50IGZyb20gdGhlDQpWRFAgYXBwcm9h Y2ggKHdoaWNoIEkgYW0gbm90IHN1cmUgdGhhdCBJIGNhbiBhZ3JlZSB3aXRoIGFzIGJlaW5nIHRo ZSByaWdodA0KYXBwcm9hY2gsIHNpbXBseSBiZWNhdXNlIGl0IGRvZXNuJ3Qgc2VlbSBzZWN1cmUp IGlzIHRoYXQsIHdpdGggdGhpcyBzY2hlbWUsDQp0aGUgVk0gZGlyZWN0bHkgZGlzY292ZXJzL3Jl Z2lzdGVycyB3aXRoIHRoZSBOVkU7IGluIHRoZSBjYXNlIG9mIHRoZSBWRFANCmFwcHJvYWNoLCBp dCBpcyB0aGUgaHlwZXJ2aXNvciB3aGljaCBkb2VzIHRoZSByZWdpc3RyYXRpb24uPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9Mz5Bbm9vcDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGJy Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5PbiBUaHUsIEp1bCAyNCwgMjAxNCBhdCAxMToy MiBBTSwgSm9lIFBlbGlzc2llciAoam9wZWxpc3MpDQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRv OmpvcGVsaXNzQGNpc2NvLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVl Pjx1PmpvcGVsaXNzQGNpc2NvLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4mZ3Q7DQp3 cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkdyZWV0aW5nczo8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTM+SXQgYXBwZWFycyB0aGF0IHRoZSBwcm90b2NvbCBpbnRyb2R1Y2VkIGluIGRyYWZ0 LWd1LW52bzMtdmlydC1lZGdlLWF1dG8tZGlzY292ZXJ5DQpsYXJnZWx5IGR1cGxpY2F0ZXMgdGhl IHdvcmsgdGhhdCB3YXMgZG9uZSBpbiBJRUVFIHdpdGggVkRQLiAmbmJzcDtJIHdvdWxkDQpsaWtl IHRvIHNvbGljaXQgdGhlIGF1dGhvcnOhryB2aWV3IG9mIHBvdGVudGlhbGx5IHVzaW5nIFZEUCBm b3IgdGhpcyBwdXJwb3NlLjwvZm9udD4NCjxwPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTM+VGhhbmtzITwvZm9udD4NCjxwPjxmb250IHNpemU9MyBjb2xvcj0jODg4 ODg4PkpvZSBQZWxpc3NpZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbnZvMyBtYWlsaW5n IGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48 YSBocmVmPW1haWx0bzpudm8zQGlldGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pm52 bzNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT48YnI+ DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9udm8zIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zPC91PjwvZm9udD48L2E+PGZvbnQgc2l6 ZT0zPjxicj4NCjwvZm9udD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbnZvMyBtYWlsaW5nIGxpc3Q8YnI+ DQpudm8zQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9udm8zPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 0055674848257D20_=-- From nobody Sun Jul 27 09:07:35 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACFC1A03DE for ; Sun, 27 Jul 2014 09:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Z6SpFjxTvb_F for ; Sun, 27 Jul 2014 09:07:29 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F51F1A0309 for ; Sun, 27 Jul 2014 09:07:29 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s6RG7SIY001628 for ; Sun, 27 Jul 2014 09:07:28 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1nc95qk1yc-15 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 27 Jul 2014 09:07:28 -0700 Received: from YK-HUB02.marvell.com (10.4.102.52) by SC-OWA.marvell.com (10.93.76.28) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sun, 27 Jul 2014 09:07:20 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by YK-HUB02.marvell.com (10.4.102.52) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sun, 27 Jul 2014 18:40:01 +0300 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.847.32; Sun, 27 Jul 2014 18:39:54 +0300 Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.0847.030; Sun, 27 Jul 2014 18:39:54 +0300 From: David Melman To: "nvo3@ietf.org" Thread-Topic: Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: Ac+pr6N78TGHnw1/RZS5iQMzG2XKqA== Date: Sun, 27 Jul 2014 15:39:54 +0000 Message-ID: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.102.232] Content-Type: multipart/alternative; boundary="_000_032948928353486bb22eee58baad15c9ILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-27_02:2014-07-25,2014-07-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=1 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407270208 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/1VoikmTTlMUz9mH_-GbT0u7NBNI Subject: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 16:07:32 -0000 --_000_032948928353486bb22eee58baad15c9ILEXCH01marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following this thread, I have a few comments: 1. To avoid confusion, drop the text about backward compatibility with VXL= AN. 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and requir= es the assignment of a new UDP port. The fact that the VXLAN-GPE header c= losely resembles VXLAN may be convenient for implementers, but this protoco= l by definition is not backward compatible with VXLAN. 3. True, the 'P' bit is not needed for backward compatibility, but I'm not = against it if there is value to make it consistent with the LISP-GPE header= . David Melman --_000_032948928353486bb22eee58baad15c9ILEXCH01marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following this thread, I have a few comments:

 

1.  To avoid confusion, drop the text about bac= kward compatibility with VXLAN. 

 

2. The VXLAN-GPE draft should focus only on the VXLA= N-GPE header and requires the assignment of a new UDP port.   The= fact that the VXLAN-GPE header closely resembles VXLAN may be convenient f= or implementers, but this protocol by definition is not backward compatible with VXLAN.    

 

3. True, the ‘P’ bit is not needed for b= ackward compatibility, but I’m not against it if there is value to ma= ke it consistent with the LISP-GPE header.

 

David Melman

 

--_000_032948928353486bb22eee58baad15c9ILEXCH01marvellcom_-- From nobody Sun Jul 27 14:22:00 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B8B1A01A8; Sun, 27 Jul 2014 14:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 gai9S9KWXrAi; Sun, 27 Jul 2014 14:21:55 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5081A00D7; Sun, 27 Jul 2014 14:21:55 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j15so6952493qaq.1 for ; Sun, 27 Jul 2014 14:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VTQUxKmJZnlk/TVANSWcZDoa0YafOxjEqyweO6/X8DE=; b=ewg/ieP1b79662qOqXfZ2j8KonHHL3wWfrtlo6EuRbfvReCkjn5S8QtGnjEIjVCjU2 nNFT/O3CLBxF05yxCO4s6G/FZZhqCXDv9C5kIAZ68ywvorKtPhP44/ml4rEqP3LC6x1j tpd77jXgW58Dl8L3v0EGLKaKN9NnuqsXGLqDFEdlP1wjzG6y4H1LDGykgfK0XujOnaA+ AVRqE3zr8yImyDCuYRpBc/iOc6oG5ogKEycMZE7b9JEGHqJH7G/+u67gy4IHu2WwI1b8 s7u1fxkwIA/eKZEAWZP8SRk8q9T6p8vxwYP8MutPK5W/FPTOWv+Wi9Ck62jl6slvRXa+ 8FpQ== X-Received: by 10.224.45.67 with SMTP id d3mr17620335qaf.11.1406496114530; Sun, 27 Jul 2014 14:21:54 -0700 (PDT) Received: from [192.168.0.10] (cblmdm72-241-167-110.buckeyecom.net. [72.241.167.110]) by mx.google.com with ESMTPSA id l76sm19950847qga.8.2014.07.27.14.21.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jul 2014 14:21:53 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> Date: Sun, 27 Jul 2014 14:21:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> To: David Melman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/ZLGBP5DI7-wrfWucKWU6ysgydxE Cc: "nvo3@ietf.org" , LISP mailing list list Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 21:21:57 -0000 > 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and = requires the assignment of a new UDP port. The fact that the VXLAN-GPE = header closely resembles VXLAN may be convenient for implementers, but = this protocol by definition is not backward compatible with VXLAN. =20 If you do that then it will be harder for VXLAN-GPE systems to = interoperate with a VXLAN systems. Because a VXLAN-GPE system will need = to open and maintain 2 UDP sockets. And an implementaiton will have to = be careful to not set the P-bit for the VXLAN socket or clear the P-bit = for VXLAN-GPE socket. This is all completely unnecessary and one way or = the other should be used. And if *it was agreed* on to use different UDP port numbers (like the = way LISP did it for L2 versus L3 packet encapsulation), we wouldn't need = the P-bit at all. But there was push back (by somebody) to not allocate = another port for VXLAN, so the demux was forced to be in the VXLAN = header.=20 And is also the reason this baggage is being carried over the LISP when = it really isn't needed. > 3. True, the =91P=92 bit is not needed for backward compatibility, but = I=92m not against it if there is value to make it consistent with the = LISP-GPE header. There is no incremental benefit to use the P-bit for LISP. We had a = solution but because of the requirement to have no new port for VXLAN, = LISP is affected. Just another example how the working group is putting effort into things = that creates more work but no benefit. Don't get me wrong, the cisco = guys did this (the VXLAN and LISP same position for P-bit) for = consistency, and they should be applauded for that. But if VXLAN could = have another port number assigned for "other protocols", maybe the = VXLAN-GPE would look so much different. Something to think about as the working group now has new productivity = mentality. Dino From nobody Sun Jul 27 17:28:05 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6A11B27C3 for ; Sun, 27 Jul 2014 17:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 8pDfebaJ1wvS for ; Sun, 27 Jul 2014 17:28:02 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BD11B27C2 for ; Sun, 27 Jul 2014 17:28:01 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so5940362iec.2 for ; Sun, 27 Jul 2014 17:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d76G85O9OmXafTuCXgBRA9Q+cOQY9qX3stEh+96oi24=; b=mfOcQLR5OINTwmBKKXVlsZ3goXL9K3ZhBCzlDKLm2zbmefqBH6ie864o/EenAZv6u0 +WchPLhc4wncJ9E4zHZw4t+ImpXVygU655/9+D3Ser8TYQvUUtyGdeI1zCdioNRmacVi WigJFsIUlI0btwxdyG4cGVaOnxUBPAqI8vqTJd7fSW5TOwE+TOz1J+JZmNB/YKKEt1ie 3EUC2jzzhUwdtLHs4UZjxYoPgqRjw5cRhWdG8kcyzpyfjzJBBaef/tL/6C83BoPYfqNz XZ1k2o4XzGFTDMOeGhNuunWHmPxE2BHbvJMqIBs+XmfPUZ3zefpweM5ojkYp4nV2PHNj E6bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d76G85O9OmXafTuCXgBRA9Q+cOQY9qX3stEh+96oi24=; b=dryCYETY6ZMPQbPUXnsqfh1ppbRs3pA4+pVj4q31uHFx/hPH91ZVbZEQNcCjduPfF8 jRYxluB9VftcY2ZMCIF24tVDaWY/eCrnoYQlseDQvhFdrlKmXvaexcW9UHWcGTvyQ0Qh MdDchxGVjovcWO53ciBIHN9fVgVXBXevrsl/PgW3QqyQlZWbF/frQ1lJZTWe8tmyeLp8 0qGfPB5gXlehbvtA2TZE9g0LtjqK18zNDt94Ogcwqz5Nr6Ag1J6zbSoKaI0CybGOHPaw MGTyj0CuZ9T5jzNHB8YTEeuBhojNrrvc/6xn7HoB8cVGNdIdPyDDK1xklYxV1OE7gs27 N9pw== X-Gm-Message-State: ALoCoQmcsBdeKHAv4GmcWXafOaZjofPXmZF2tLiawegyNc6MLsb9x2STJaF6VQrJRacEVldMgzVU MIME-Version: 1.0 X-Received: by 10.50.43.234 with SMTP id z10mr26894404igl.28.1406507281221; Sun, 27 Jul 2014 17:28:01 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Sun, 27 Jul 2014 17:28:01 -0700 (PDT) In-Reply-To: <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> Date: Sun, 27 Jul 2014 17:28:01 -0700 Message-ID: From: Tom Herbert To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/tzGEFPfRJHN8Ot8lH7a6dkPclho Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 00:28:03 -0000 On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci wrote= : >> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and req= uires the assignment of a new UDP port. The fact that the VXLAN-GPE heade= r closely resembles VXLAN may be convenient for implementers, but this prot= ocol by definition is not backward compatible with VXLAN. > > If you do that then it will be harder for VXLAN-GPE systems to interopera= te with a VXLAN systems. Because a VXLAN-GPE system will need to open and m= aintain 2 UDP sockets. And an implementaiton will have to be careful to not= set the P-bit for the VXLAN socket or clear the P-bit for VXLAN-GPE socket= . This is all completely unnecessary and one way or the other should be use= d. > I am not sure what you are suggesting. AFAICT there is no backwards compatible means to to add the protocol field to VXLAN which is the motivation for the new UDP port, which in turn implies a new protocol (which also implies an opportunity to add a more general set of protocol features like version number and options extensions which are also not backwards compatible). Maybe it's possible to break compatibility within the protocol and assume that out of band mechanisms could negotiate use of P-bit to compensate, but I assume there's already quite a bit of VXLAN deployment so that seems pretty shaky robustness-wise to me. It's not just adding the protocol field that would be an issue, even adding the OAM bit to VXLAN would be problematic. Per VXLAN spec unspecified flag bits are ignored on receive, so if the OAM bit were subsequently defined in VXLAN it will be ignored by existing implementations and these packets will be processed normally-- this seems to be incompatible with the proposed VXLAN-gpe requirement that "When the O bit is set to 1, the packet is an OAM packet and OAM processing MUST occur." (btw 'OAM processing' is awfully ambiguous to be a MUST here IMO). Allowing the reserved bits in the header to be ignored on receive limits the usefulness in that new bits that are defined can only be advisory and not fundamentally change interpretation of the packet. Had the requirement in VXLAN been that packets with unknown bits set be dropped, then adding P-bit and O-bit could have been done with backwards compatibility. This might be a reasonable requirement to consider if new protocol (i.e. new port number) is undertaken. Thanks, Tom > And if *it was agreed* on to use different UDP port numbers (like the way= LISP did it for L2 versus L3 packet encapsulation), we wouldn't need the P= -bit at all. But there was push back (by somebody) to not allocate another = port for VXLAN, so the demux was forced to be in the VXLAN header. > > And is also the reason this baggage is being carried over the LISP when i= t really isn't needed. > >> 3. True, the =E2=80=98P=E2=80=99 bit is not needed for backward compatib= ility, but I=E2=80=99m not against it if there is value to make it consiste= nt with the LISP-GPE header. > > There is no incremental benefit to use the P-bit for LISP. We had a solut= ion but because of the requirement to have no new port for VXLAN, LISP is a= ffected. > > Just another example how the working group is putting effort into things = that creates more work but no benefit. Don't get me wrong, the cisco guys d= id this (the VXLAN and LISP same position for P-bit) for consistency, and t= hey should be applauded for that. But if VXLAN could have another port numb= er assigned for "other protocols", maybe the VXLAN-GPE would look so much d= ifferent. > > Something to think about as the working group now has new productivity me= ntality. > > Dino > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Sun Jul 27 17:39:20 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24BD1B27CA; Sun, 27 Jul 2014 17:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7EXvKtpMJ17M; Sun, 27 Jul 2014 17:39:14 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A37B1B27C7; Sun, 27 Jul 2014 17:39:14 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id w8so7107573qac.30 for ; Sun, 27 Jul 2014 17:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4Zc4wsjEP52OJxm5cFCKSbazVDXmcvkuvZcg5nrFqTs=; b=V+lrqm53w9W0FC0bbp94A6SDE0NAQxESF76A5rlxhun8UpnAZQjcIhiSOkMbu1Ma+R y/zEnHDJXjGjDT/2bJUIk1cUGP4XZe0kV6wLw1/+1rj/ZRDHvSxwqEXq5VkkjTJmJh1c rgzOrMahOh0OW60JqwluJQRfTjOns9VVGl2+RrzyHGZcG9tJQI9fs65jMcgGe7/00s0T z42BAHNW+zAYr66uPrbbwykD52Gobp7kNITnINgQGCAiY+F+FJoD3G88MPF7tmwz+XMC 1tkMH0kVcdez+0tH2qdH4OyDOU/kbCXb+9hCQzCnodKfZGZ8YG4lzEiNcoqraUXLOSEW nhyA== X-Received: by 10.224.54.136 with SMTP id q8mr53008578qag.79.1406507952771; Sun, 27 Jul 2014 17:39:12 -0700 (PDT) Received: from [192.168.0.8] (cblmdm72-241-167-110.buckeyecom.net. [72.241.167.110]) by mx.google.com with ESMTPSA id u3sm26224773qas.2.2014.07.27.17.39.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jul 2014 17:39:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sun, 27 Jul 2014 20:39:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> To: Tom Herbert Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/jV8dgnKQD6WzY0oKmFm-4fXk5SI Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 00:39:17 -0000 I am going to let other people explain. I think my email was clear.=20 Dino > On Jul 27, 2014, at 8:28 PM, Tom Herbert wrote: >=20 > On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci wrot= e: >>> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and req= uires the assignment of a new UDP port. The fact that the VXLAN-GPE header= closely resembles VXLAN may be convenient for implementers, but this protoc= ol by definition is not backward compatible with VXLAN. >>=20 >> If you do that then it will be harder for VXLAN-GPE systems to interopera= te with a VXLAN systems. Because a VXLAN-GPE system will need to open and ma= intain 2 UDP sockets. And an implementaiton will have to be careful to not s= et the P-bit for the VXLAN socket or clear the P-bit for VXLAN-GPE socket. T= his is all completely unnecessary and one way or the other should be used. > I am not sure what you are suggesting. AFAICT there is no backwards > compatible means to to add the protocol field to VXLAN which is the > motivation for the new UDP port, which in turn implies a new protocol > (which also implies an opportunity to add a more general set of > protocol features like version number and options extensions which are > also not backwards compatible). Maybe it's possible to break > compatibility within the protocol and assume that out of band > mechanisms could negotiate use of P-bit to compensate, but I assume > there's already quite a bit of VXLAN deployment so that seems pretty > shaky robustness-wise to me. >=20 > It's not just adding the protocol field that would be an issue, even > adding the OAM bit to VXLAN would be problematic. Per VXLAN spec > unspecified flag bits are ignored on receive, so if the OAM bit were > subsequently defined in VXLAN it will be ignored by existing > implementations and these packets will be processed normally-- this > seems to be incompatible with the proposed VXLAN-gpe requirement that > "When the O bit is set to 1, the packet is an OAM packet and OAM > processing MUST occur." (btw 'OAM processing' is awfully ambiguous to > be a MUST here IMO). >=20 > Allowing the reserved bits in the header to be ignored on receive > limits the usefulness in that new bits that are defined can only be > advisory and not fundamentally change interpretation of the packet. > Had the requirement in VXLAN been that packets with unknown bits set > be dropped, then adding P-bit and O-bit could have been done with > backwards compatibility. This might be a reasonable requirement to > consider if new protocol (i.e. new port number) is undertaken. >=20 > Thanks, > Tom >=20 >> And if *it was agreed* on to use different UDP port numbers (like the way= LISP did it for L2 versus L3 packet encapsulation), we wouldn't need the P-= bit at all. But there was push back (by somebody) to not allocate another po= rt for VXLAN, so the demux was forced to be in the VXLAN header. >>=20 >> And is also the reason this baggage is being carried over the LISP when i= t really isn't needed. >>=20 >>> 3. True, the =E2=80=98P=E2=80=99 bit is not needed for backward compatib= ility, but I=E2=80=99m not against it if there is value to make it consisten= t with the LISP-GPE header. >>=20 >> There is no incremental benefit to use the P-bit for LISP. We had a solut= ion but because of the requirement to have no new port for VXLAN, LISP is af= fected. >>=20 >> Just another example how the working group is putting effort into things t= hat creates more work but no benefit. Don't get me wrong, the cisco guys did= this (the VXLAN and LISP same position for P-bit) for consistency, and they= should be applauded for that. But if VXLAN could have another port number a= ssigned for "other protocols", maybe the VXLAN-GPE would look so much differ= ent. >>=20 >> Something to think about as the working group now has new productivity me= ntality. >>=20 >> Dino >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From nobody Sun Jul 27 23:57:51 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452211A008C; Sun, 27 Jul 2014 23:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 yIb4UFHPIO_6; Sun, 27 Jul 2014 23:57:45 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8BD1A0278; Sun, 27 Jul 2014 23:57:44 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 5258A2AA0F; Mon, 28 Jul 2014 06:57:41 +0000 (GMT) Date: Sun, 27 Jul 2014 23:58:48 -0700 From: Marc Binderberger To: Tom Herbert , Dino Farinacci , David Melman Message-ID: <20140727235848276183.21b2fe35@sniff.de> In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/ZndEBXoCEDik9ftYuhlBJrKGCdk Cc: "nvo3@ietf.org" , LISP mailing list list Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 06:57:47 -0000 SGVsbG8gVG9tLA0KDQpJJ20gYWxsIGZvciBwcmVjaXNlIHdvcmRpbmcgLSBidXQgb25lIHNo b3VsZG4ndCBnZXQgbG9zdCBpbiB0aGUgd29yZGluZyA6LSkNCg0KVGhlIGludGVudGlvbiBv ZiB0aGUgImNvbXBhdGliaWxpdHkiIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgc2hvdWxkIGJl IGNsZWFyLCANCmFsdGhvdWdoIHRoZSB3b3JkIGlzIGNvbmZ1c2luZzogeW91IGNhbiByZS11 c2UgeW91ciAiZ3BlIiBzZW5kL3JlY2VpdmUgbG9naWMgDQp0byBzZW5kL3JlY2VpdmUgdGhl IGV4aXN0aW5nIFZ4TEFOIGVuY2Fwcy4gQWxsIHlvdSBuZWVkIGlzIHRvIHNlbmQvcmVjZWl2 ZSBvbiANCjQ3ODkvdWRwIGluc3RlYWQgb2YgdGhlIHRvLWJlLWRlZmluZWQgZ3BlIHBvcnQg YW5kIHNldCB0aGUgZmxhZ3MvZmllbGRzIA0KYWNjb3JkaW5nbHkuDQoNClRoZSBwb2ludCBE aW5vIG1ha2VzIGlzIChJIHRoaW5rKTogaXMgdGhlcmUgcmVhbGx5IGEgZ2FpbiB0byAicmUt aW52ZW50IiANClZ4TEFOIGFuZCBMSVNQIGRhdGEgZW5jYXBzdWxhdGlvbj8gQW5kIGl0IG1p Z2h0IGJlIGFjdHVhbGx5IGVhc2llciB0byANCmltcGxlbWVudCBhbmQgdGVzdCBzZXBhcmF0 ZSBlbmNvZGluZ3MgaW5zdGVhZCBvZiB0aGUgbW9yZSBjb21wbGV4IGNvbWJpbmVkIA0KaGVh ZGVyIGluIFZ4TEFOLWdwZS4NCg0KVGhlIGNvc3Qgb2Ygbm90IGNvbWJpbmluZyBpcyBhIHBv dGVudGlhbCBhZGRpdGlvbmFsIG50aCBoZWFkZXIgZm9yIFNGQyBhbmQgDQp3aGF0ZXZlciBl bHNlIG1heSBjb21lLg0KDQoNCj4gQWxsb3dpbmcgdGhlIHJlc2VydmVkIGJpdHMgaW4gdGhl IGhlYWRlciB0byBiZSBpZ25vcmVkIG9uIHJlY2VpdmUNCj4gbGltaXRzIHRoZSB1c2VmdWxu ZXNzIGluIHRoYXQgbmV3IGJpdHMgdGhhdCBhcmUgZGVmaW5lZCBjYW4gb25seSBiZQ0KPiBh ZHZpc29yeSBhbmQgbm90IGZ1bmRhbWVudGFsbHkgY2hhbmdlIGludGVycHJldGF0aW9uIG9m IHRoZSBwYWNrZXQuDQoNCkkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudCBpbiB0aGUgMm5k IGhhbGYgYnV0IG5vdCB5b3VyIG9waW5pb24gYWJvdXQgdGhlIA0KdXNlZnVsbmVzcy4gRG9u J3Qgc2VlIGEgcHJvYmxlbSBoZXJlLCBMSVNQIGlzIGEgZ29vZCBleGFtcGxlIGhvdyBpZ25v cmluZyANCnVua25vd24gZmxhZ3Mgd29ya3Mgd2VsbC4NCg0KDQpSZWdhcmRzLCBNYXJjDQoN Cg0KDQpPbiBTdW4sIDI3IEp1bCAyMDE0IDE3OjI4OjAxIC0wNzAwLCBUb20gSGVyYmVydCB3 cm90ZToNCj4gT24gU3VuLCBKdWwgMjcsIDIwMTQgYXQgMjoyMSBQTSwgRGlubyBGYXJpbmFj Y2kgPGZhcmluYWNjaUBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IDIuIFRoZSBWWExBTi1HUEUg ZHJhZnQgc2hvdWxkIGZvY3VzIG9ubHkgb24gdGhlIFZYTEFOLUdQRSBoZWFkZXIgYW5kIA0K Pj4+IHJlcXVpcmVzIHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUCBwb3J0LiAgIFRoZSBm YWN0IHRoYXQgdGhlIFZYTEFOLUdQRSANCj4+PiBoZWFkZXIgY2xvc2VseSByZXNlbWJsZXMg VlhMQU4gbWF5IGJlIGNvbnZlbmllbnQgZm9yIGltcGxlbWVudGVycywgYnV0IA0KPj4+IHRo aXMgcHJvdG9jb2wgYnkgZGVmaW5pdGlvbiBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZSB3 aXRoIFZYTEFOLg0KPj4gDQo+PiBJZiB5b3UgZG8gdGhhdCB0aGVuIGl0IHdpbGwgYmUgaGFy ZGVyIGZvciBWWExBTi1HUEUgc3lzdGVtcyB0byANCj4+IGludGVyb3BlcmF0ZSB3aXRoIGEg VlhMQU4gc3lzdGVtcy4gQmVjYXVzZSBhIFZYTEFOLUdQRSBzeXN0ZW0gd2lsbCBuZWVkIHRv IA0KPj4gb3BlbiBhbmQgbWFpbnRhaW4gMiBVRFAgc29ja2V0cy4gQW5kIGFuIGltcGxlbWVu dGFpdG9uIHdpbGwgaGF2ZSB0byBiZSANCj4+IGNhcmVmdWwgdG8gbm90IHNldCB0aGUgUC1i aXQgZm9yIHRoZSBWWExBTiBzb2NrZXQgb3IgY2xlYXIgdGhlIFAtYml0IGZvciANCj4+IFZY TEFOLUdQRSBzb2NrZXQuIFRoaXMgaXMgYWxsIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnkgYW5k IG9uZSB3YXkgb3IgdGhlIA0KPj4gb3RoZXIgc2hvdWxkIGJlIHVzZWQuDQo+PiANCj4gSSBh bSBub3Qgc3VyZSB3aGF0IHlvdSBhcmUgc3VnZ2VzdGluZy4gQUZBSUNUIHRoZXJlIGlzIG5v IGJhY2t3YXJkcw0KPiBjb21wYXRpYmxlIG1lYW5zIHRvIHRvIGFkZCB0aGUgcHJvdG9jb2wg ZmllbGQgdG8gVlhMQU4gd2hpY2ggaXMgdGhlDQo+IG1vdGl2YXRpb24gZm9yIHRoZSBuZXcg VURQIHBvcnQsIHdoaWNoIGluIHR1cm4gaW1wbGllcyBhIG5ldyBwcm90b2NvbA0KPiAod2hp Y2ggYWxzbyBpbXBsaWVzIGFuIG9wcG9ydHVuaXR5IHRvIGFkZCBhIG1vcmUgZ2VuZXJhbCBz ZXQgb2YNCj4gcHJvdG9jb2wgZmVhdHVyZXMgbGlrZSB2ZXJzaW9uIG51bWJlciBhbmQgb3B0 aW9ucyBleHRlbnNpb25zIHdoaWNoIGFyZQ0KPiBhbHNvIG5vdCBiYWNrd2FyZHMgY29tcGF0 aWJsZSkuIE1heWJlIGl0J3MgcG9zc2libGUgdG8gYnJlYWsNCj4gY29tcGF0aWJpbGl0eSB3 aXRoaW4gdGhlIHByb3RvY29sIGFuZCBhc3N1bWUgdGhhdCBvdXQgb2YgYmFuZA0KPiBtZWNo YW5pc21zIGNvdWxkIG5lZ290aWF0ZSB1c2Ugb2YgUC1iaXQgdG8gY29tcGVuc2F0ZSwgYnV0 IEkgYXNzdW1lDQo+IHRoZXJlJ3MgYWxyZWFkeSBxdWl0ZSBhIGJpdCBvZiBWWExBTiBkZXBs b3ltZW50IHNvIHRoYXQgc2VlbXMgcHJldHR5DQo+IHNoYWt5IHJvYnVzdG5lc3Mtd2lzZSB0 byBtZS4NCj4gDQo+IEl0J3Mgbm90IGp1c3QgYWRkaW5nIHRoZSBwcm90b2NvbCBmaWVsZCB0 aGF0IHdvdWxkIGJlIGFuIGlzc3VlLCBldmVuDQo+IGFkZGluZyB0aGUgT0FNIGJpdCB0byBW WExBTiB3b3VsZCBiZSBwcm9ibGVtYXRpYy4gUGVyIFZYTEFOIHNwZWMNCj4gdW5zcGVjaWZp ZWQgZmxhZyBiaXRzIGFyZSBpZ25vcmVkIG9uIHJlY2VpdmUsIHNvIGlmIHRoZSBPQU0gYml0 IHdlcmUNCj4gc3Vic2VxdWVudGx5IGRlZmluZWQgaW4gVlhMQU4gaXQgd2lsbCBiZSBpZ25v cmVkIGJ5IGV4aXN0aW5nDQo+IGltcGxlbWVudGF0aW9ucyBhbmQgdGhlc2UgcGFja2V0cyB3 aWxsIGJlIHByb2Nlc3NlZCBub3JtYWxseS0tIHRoaXMNCj4gc2VlbXMgdG8gYmUgaW5jb21w YXRpYmxlIHdpdGggdGhlIHByb3Bvc2VkIFZYTEFOLWdwZSByZXF1aXJlbWVudCB0aGF0DQo+ ICJXaGVuIHRoZSBPIGJpdCBpcyBzZXQgdG8gMSwgdGhlIHBhY2tldCBpcyBhbiBPQU0gcGFj a2V0IGFuZCBPQU0NCj4gcHJvY2Vzc2luZyBNVVNUIG9jY3VyLiIgKGJ0dyAnT0FNIHByb2Nl c3NpbmcnIGlzIGF3ZnVsbHkgYW1iaWd1b3VzIHRvDQo+IGJlIGEgTVVTVCBoZXJlIElNTyku DQo+IA0KPiBBbGxvd2luZyB0aGUgcmVzZXJ2ZWQgYml0cyBpbiB0aGUgaGVhZGVyIHRvIGJl IGlnbm9yZWQgb24gcmVjZWl2ZQ0KPiBsaW1pdHMgdGhlIHVzZWZ1bG5lc3MgaW4gdGhhdCBu ZXcgYml0cyB0aGF0IGFyZSBkZWZpbmVkIGNhbiBvbmx5IGJlDQo+IGFkdmlzb3J5IGFuZCBu b3QgZnVuZGFtZW50YWxseSBjaGFuZ2UgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHBhY2tldC4N Cj4gSGFkIHRoZSByZXF1aXJlbWVudCBpbiBWWExBTiBiZWVuIHRoYXQgcGFja2V0cyB3aXRo IHVua25vd24gYml0cyBzZXQNCj4gYmUgZHJvcHBlZCwgdGhlbiBhZGRpbmcgUC1iaXQgYW5k IE8tYml0IGNvdWxkIGhhdmUgYmVlbiBkb25lIHdpdGgNCj4gYmFja3dhcmRzIGNvbXBhdGli aWxpdHkuIFRoaXMgbWlnaHQgYmUgYSByZWFzb25hYmxlIHJlcXVpcmVtZW50IHRvDQo+IGNv bnNpZGVyIGlmIG5ldyBwcm90b2NvbCAoaS5lLiBuZXcgcG9ydCBudW1iZXIpIGlzIHVuZGVy dGFrZW4uDQo+IA0KPiBUaGFua3MsDQo+IFRvbQ0KPiANCj4+IEFuZCBpZiAqaXQgd2FzIGFn cmVlZCogb24gdG8gdXNlIGRpZmZlcmVudCBVRFAgcG9ydCBudW1iZXJzIChsaWtlIHRoZSB3 YXkgDQo+PiBMSVNQIGRpZCBpdCBmb3IgTDIgdmVyc3VzIEwzIHBhY2tldCBlbmNhcHN1bGF0 aW9uKSwgd2Ugd291bGRuJ3QgbmVlZCB0aGUgDQo+PiBQLWJpdCBhdCBhbGwuIEJ1dCB0aGVy ZSB3YXMgcHVzaCBiYWNrIChieSBzb21lYm9keSkgdG8gbm90IGFsbG9jYXRlIA0KPj4gYW5v dGhlciBwb3J0IGZvciBWWExBTiwgc28gdGhlIGRlbXV4IHdhcyBmb3JjZWQgdG8gYmUgaW4g dGhlIFZYTEFOIGhlYWRlci4NCj4+IA0KPj4gQW5kIGlzIGFsc28gdGhlIHJlYXNvbiB0aGlz IGJhZ2dhZ2UgaXMgYmVpbmcgY2FycmllZCBvdmVyIHRoZSBMSVNQIHdoZW4gaXQgDQo+PiBy ZWFsbHkgaXNuJ3QgbmVlZGVkLg0KPj4gDQo+Pj4gMy4gVHJ1ZSwgdGhlIKFQoiBiaXQgaXMg bm90IG5lZWRlZCBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgYnV0IEmibSANCj4+PiBu b3QgYWdhaW5zdCBpdCBpZiB0aGVyZSBpcyB2YWx1ZSB0byBtYWtlIGl0IGNvbnNpc3RlbnQg d2l0aCB0aGUgTElTUC1HUEUgDQo+Pj4gaGVhZGVyLg0KPj4gDQo+PiBUaGVyZSBpcyBubyBp bmNyZW1lbnRhbCBiZW5lZml0IHRvIHVzZSB0aGUgUC1iaXQgZm9yIExJU1AuIFdlIGhhZCBh IA0KPj4gc29sdXRpb24gYnV0IGJlY2F1c2Ugb2YgdGhlIHJlcXVpcmVtZW50IHRvIGhhdmUg bm8gbmV3IHBvcnQgZm9yIFZYTEFOLCANCj4+IExJU1AgaXMgYWZmZWN0ZWQuDQo+PiANCj4+ IEp1c3QgYW5vdGhlciBleGFtcGxlIGhvdyB0aGUgd29ya2luZyBncm91cCBpcyBwdXR0aW5n IGVmZm9ydCBpbnRvIHRoaW5ncyANCj4+IHRoYXQgY3JlYXRlcyBtb3JlIHdvcmsgYnV0IG5v IGJlbmVmaXQuIERvbid0IGdldCBtZSB3cm9uZywgdGhlIGNpc2NvIGd1eXMgDQo+PiBkaWQg dGhpcyAodGhlIFZYTEFOIGFuZCBMSVNQIHNhbWUgcG9zaXRpb24gZm9yIFAtYml0KSBmb3Ig Y29uc2lzdGVuY3ksIGFuZCANCj4+IHRoZXkgc2hvdWxkIGJlIGFwcGxhdWRlZCBmb3IgdGhh dC4gQnV0IGlmIFZYTEFOIGNvdWxkIGhhdmUgYW5vdGhlciBwb3J0IA0KPj4gbnVtYmVyIGFz c2lnbmVkIGZvciAib3RoZXIgcHJvdG9jb2xzIiwgbWF5YmUgdGhlIFZYTEFOLUdQRSB3b3Vs ZCBsb29rIHNvIA0KPj4gbXVjaCBkaWZmZXJlbnQuDQo+PiANCj4+IFNvbWV0aGluZyB0byB0 aGluayBhYm91dCBhcyB0aGUgd29ya2luZyBncm91cCBub3cgaGFzIG5ldyBwcm9kdWN0aXZp dHkgDQo+PiBtZW50YWxpdHkuDQo+PiANCj4+IERpbm8NCj4+IA0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG52bzMgbWFpbGluZyBs aXN0DQo+PiBudm8zQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL252bzMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8z From nobody Mon Jul 28 03:14:17 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE4E1A0382; Mon, 28 Jul 2014 03:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 gmZ3Ws-0mBCT; Mon, 28 Jul 2014 03:14:04 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6A91A036C; Mon, 28 Jul 2014 03:14:03 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so6451825ieb.18 for ; Mon, 28 Jul 2014 03:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZEkHpEauRBXR2i8nDtysMvn2/0Ch1jQhs4Puk77j+pY=; b=oC5n8Y9pIr2E75R/Y5FXNa/jmrmim/rjXaGI+RLAznBMOXXvXNUW10p8UbiqAOsGlr YBjT4i2IyWL+EclPsko1VumDu0UTEAkTG1lyjXsn8a8K2L41Lqgl/kWdLtHdhFEQv7EO NQFWi0ss52nfkiObuwkd3sfEDLmMIbJdsPl9COf8+pN+NWcTIfwP4jwrTSOBqRcDSKPk tiop7nwFM0wSYmBJLd/3lm/JgU4WgCchYEv19vBCn9uIB8/PQPigYbpqBT7VZQ3R0ZUA tMG48Gykp5UEjzuDTdmqfEO0RQ6rl2Osvwl4WZMKHBTTGYmvLSmD11nNxG5C25dPizf9 UQeQ== X-Received: by 10.50.50.175 with SMTP id d15mr30495310igo.35.1406542443289; Mon, 28 Jul 2014 03:14:03 -0700 (PDT) Received: from [10.173.63.228] ([166.137.94.111]) by mx.google.com with ESMTPSA id bf4sm25396212igb.17.2014.07.28.03.14.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 03:14:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: <20140727235848276183.21b2fe35@sniff.de> Date: Mon, 28 Jul 2014 06:14:02 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3CAE1D58-3277-4B8E-A4AF-F52CC81192D6@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> To: Marc Binderberger Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/uSwuKTltXAzheMJi4TxVTc_g9jU Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 10:14:07 -0000 > The point Dino makes is (I think): is there really a gain to "re-invent" > VxLAN and LISP data encapsulation? And it might be actually easier to > implement and test separate encodings instead of the more complex combined > header in VxLAN-gpe. Exactly. Dino From nobody Mon Jul 28 05:24:29 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7F31A0515; Mon, 28 Jul 2014 05:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DzpZchegv3jF; Mon, 28 Jul 2014 05:24:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7601A0174; Mon, 28 Jul 2014 05:24:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKP64751; Mon, 28 Jul 2014 12:24:22 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Jul 2014 13:24:22 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 28 Jul 2014 20:24:16 +0800 From: Haoweiguo To: Dino Farinacci , Tom Herbert Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqkzAsneDBkHiT0W0YABoAmZP/5u1ZM/Q Date: Mon, 28 Jul 2014 12:24:15 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.12.133] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/9CXQG7KgApiINJvwkonOyRiKtLs Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list Subject: [nvo3] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9uIGh0dHA6Ly90b29scy5p?= =?gb2312?b?ZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:24:27 -0000 QWJvdXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaSBhbHNvIGFncmVlIHdpdGggRGluby4gVlhM QU4tR1BFIHNob3VsZCBmb2N1cyBvbiAgdGhlIFZYTEFOLUdQRSBoZWFkZXIgYW5kIHJlcXVpcmVz IHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUCBwb3J0LCB0aGUgZGF0YSBmb3JtYXQgZG9uJ3Qg bmVlZCBjb25zaWRlciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggVlhMQU4gaGVhZGVyLiBJ ZiBOVkUxIHN1cHBvcnQgVlhMQU4tR1BFLCBhbm90aGVyIE5WRTIgc3VwcG9ydCBWWExBTiwgdGhl IHR3byBOVkUgY2FuIGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhlciwgbm8gbWF0dGVyIGludGVy LXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgb3IgaW50cmEtc3VibmV0IGxheWVyIDIgdHJhZmZpYy4N CldoZW4gaW5ncmVzcyBOVkUgc2VuZHMgdHJhZmZpYyB0byBlZ3Jlc3MgTlZFLCBpbmdyZXNzIE5W RSBzaG91bGQgdXNlIHRoZSBkYXRhIGZvcm1hdCBvZiBlZ3Jlc3MgTlZFLCBpLmUuLCB3aGVuIE5W RTEgc2VuZHMgdHJhZmZpYyB0byBOVkUyLCBOVkUxIHNob3VsZCB1c2UgVlhMQU4gZW5jYXBzdWxh dGlvbi4gV2hlbiBOVkUyIHNlbmRzIHRyYWZmaWMgdG8gTlZFMSwgTlZFMSBzaG91bGQgdXNlIFZY TEFOLUdQRSBoZWFkZXIuDQpBbHRob3VnaCBWWExBTiBjdXJyZW50bHkgb25seSBzdXBwb3J0IEV0 aGVybmV0IGluIFVEUCwgIGxheWVyIDMgaW50ZXItc3VibmV0IHRyYWZmaWMgZm9yd2FyZGluZyBi ZXR3ZWVuIE5WRXMgY2FuIGFsc28gYmUgc3VwcG9ydGVkLCBpbm5lciBkZXN0aW5hdGlvbiBNQUMg Y2FuIGJlIHVzZWQgdG8gZGlmZmVyZW5jaWF0ZSBpbnRlci1zdWJuZXQgbGF5ZXIgMyB0cmFmZmlj IGZyb20gaW50cmEtc3VibmV0IGxheWVyIDIgdHJhZmZpYyBvbiBlZ3Jlc3MgTlZFLCBpbm5lciBk ZXN0aW5hdGlvbiBNQUMgc2hvdWxkIGJlIHNldCBnYXRld2F5IGludGVyZmFjZSBNQUMgb2YgZWdy ZXNzIE5WRSBpbiBpbnRlci1zdWJuZXQgY29tbXVuaWNhdGlvbiBjYXNlLg0KVGhhbmtzDQp3ZWln dW8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogRGlu byBGYXJpbmFjY2kgW2ZhcmluYWNjaUBnbWFpbC5jb21dDQq3osvNyrG85DogMjAxNMTqN9TCMjjI 1SA4OjM5DQrK1bz+yMs6IFRvbSBIZXJiZXJ0DQqzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0 Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3QNCtb3zOI6IFJlOiBbbnZvM10gQ29tbWVudHMg b24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQoN CkkgYW0gZ29pbmcgdG8gbGV0IG90aGVyIHBlb3BsZSBleHBsYWluLiBJIHRoaW5rIG15IGVtYWls IHdhcyBjbGVhci4NCg0KRGlubw0KDQo+IE9uIEp1bCAyNywgMjAxNCwgYXQgODoyOCBQTSwgVG9t IEhlcmJlcnQgPHRoZXJiZXJ0QGdvb2dsZS5jb20+IHdyb3RlOg0KPg0KPiBPbiBTdW4sIEp1bCAy NywgMjAxNCBhdCAyOjIxIFBNLCBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4g d3JvdGU6DQo+Pj4gMi4gVGhlIFZYTEFOLUdQRSBkcmFmdCBzaG91bGQgZm9jdXMgb25seSBvbiB0 aGUgVlhMQU4tR1BFIGhlYWRlciBhbmQgcmVxdWlyZXMgdGhlIGFzc2lnbm1lbnQgb2YgYSBuZXcg VURQIHBvcnQuICAgVGhlIGZhY3QgdGhhdCB0aGUgVlhMQU4tR1BFIGhlYWRlciBjbG9zZWx5IHJl c2VtYmxlcyBWWExBTiBtYXkgYmUgY29udmVuaWVudCBmb3IgaW1wbGVtZW50ZXJzLCBidXQgdGhp cyBwcm90b2NvbCBieSBkZWZpbml0aW9uIGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGgg VlhMQU4uDQo+Pg0KPj4gSWYgeW91IGRvIHRoYXQgdGhlbiBpdCB3aWxsIGJlIGhhcmRlciBmb3Ig VlhMQU4tR1BFIHN5c3RlbXMgdG8gaW50ZXJvcGVyYXRlIHdpdGggYSBWWExBTiBzeXN0ZW1zLiBC ZWNhdXNlIGEgVlhMQU4tR1BFIHN5c3RlbSB3aWxsIG5lZWQgdG8gb3BlbiBhbmQgbWFpbnRhaW4g MiBVRFAgc29ja2V0cy4gQW5kIGFuIGltcGxlbWVudGFpdG9uIHdpbGwgaGF2ZSB0byBiZSBjYXJl ZnVsIHRvIG5vdCBzZXQgdGhlIFAtYml0IGZvciB0aGUgVlhMQU4gc29ja2V0IG9yIGNsZWFyIHRo ZSBQLWJpdCBmb3IgVlhMQU4tR1BFIHNvY2tldC4gVGhpcyBpcyBhbGwgY29tcGxldGVseSB1bm5l Y2Vzc2FyeSBhbmQgb25lIHdheSBvciB0aGUgb3RoZXIgc2hvdWxkIGJlIHVzZWQuDQo+IEkgYW0g bm90IHN1cmUgd2hhdCB5b3UgYXJlIHN1Z2dlc3RpbmcuIEFGQUlDVCB0aGVyZSBpcyBubyBiYWNr d2FyZHMNCj4gY29tcGF0aWJsZSBtZWFucyB0byB0byBhZGQgdGhlIHByb3RvY29sIGZpZWxkIHRv IFZYTEFOIHdoaWNoIGlzIHRoZQ0KPiBtb3RpdmF0aW9uIGZvciB0aGUgbmV3IFVEUCBwb3J0LCB3 aGljaCBpbiB0dXJuIGltcGxpZXMgYSBuZXcgcHJvdG9jb2wNCj4gKHdoaWNoIGFsc28gaW1wbGll cyBhbiBvcHBvcnR1bml0eSB0byBhZGQgYSBtb3JlIGdlbmVyYWwgc2V0IG9mDQo+IHByb3RvY29s IGZlYXR1cmVzIGxpa2UgdmVyc2lvbiBudW1iZXIgYW5kIG9wdGlvbnMgZXh0ZW5zaW9ucyB3aGlj aCBhcmUNCj4gYWxzbyBub3QgYmFja3dhcmRzIGNvbXBhdGlibGUpLiBNYXliZSBpdCdzIHBvc3Np YmxlIHRvIGJyZWFrDQo+IGNvbXBhdGliaWxpdHkgd2l0aGluIHRoZSBwcm90b2NvbCBhbmQgYXNz dW1lIHRoYXQgb3V0IG9mIGJhbmQNCj4gbWVjaGFuaXNtcyBjb3VsZCBuZWdvdGlhdGUgdXNlIG9m IFAtYml0IHRvIGNvbXBlbnNhdGUsIGJ1dCBJIGFzc3VtZQ0KPiB0aGVyZSdzIGFscmVhZHkgcXVp dGUgYSBiaXQgb2YgVlhMQU4gZGVwbG95bWVudCBzbyB0aGF0IHNlZW1zIHByZXR0eQ0KPiBzaGFr eSByb2J1c3RuZXNzLXdpc2UgdG8gbWUuDQo+DQo+IEl0J3Mgbm90IGp1c3QgYWRkaW5nIHRoZSBw cm90b2NvbCBmaWVsZCB0aGF0IHdvdWxkIGJlIGFuIGlzc3VlLCBldmVuDQo+IGFkZGluZyB0aGUg T0FNIGJpdCB0byBWWExBTiB3b3VsZCBiZSBwcm9ibGVtYXRpYy4gUGVyIFZYTEFOIHNwZWMNCj4g dW5zcGVjaWZpZWQgZmxhZyBiaXRzIGFyZSBpZ25vcmVkIG9uIHJlY2VpdmUsIHNvIGlmIHRoZSBP QU0gYml0IHdlcmUNCj4gc3Vic2VxdWVudGx5IGRlZmluZWQgaW4gVlhMQU4gaXQgd2lsbCBiZSBp Z25vcmVkIGJ5IGV4aXN0aW5nDQo+IGltcGxlbWVudGF0aW9ucyBhbmQgdGhlc2UgcGFja2V0cyB3 aWxsIGJlIHByb2Nlc3NlZCBub3JtYWxseS0tIHRoaXMNCj4gc2VlbXMgdG8gYmUgaW5jb21wYXRp YmxlIHdpdGggdGhlIHByb3Bvc2VkIFZYTEFOLWdwZSByZXF1aXJlbWVudCB0aGF0DQo+ICJXaGVu IHRoZSBPIGJpdCBpcyBzZXQgdG8gMSwgdGhlIHBhY2tldCBpcyBhbiBPQU0gcGFja2V0IGFuZCBP QU0NCj4gcHJvY2Vzc2luZyBNVVNUIG9jY3VyLiIgKGJ0dyAnT0FNIHByb2Nlc3NpbmcnIGlzIGF3 ZnVsbHkgYW1iaWd1b3VzIHRvDQo+IGJlIGEgTVVTVCBoZXJlIElNTykuDQo+DQo+IEFsbG93aW5n IHRoZSByZXNlcnZlZCBiaXRzIGluIHRoZSBoZWFkZXIgdG8gYmUgaWdub3JlZCBvbiByZWNlaXZl DQo+IGxpbWl0cyB0aGUgdXNlZnVsbmVzcyBpbiB0aGF0IG5ldyBiaXRzIHRoYXQgYXJlIGRlZmlu ZWQgY2FuIG9ubHkgYmUNCj4gYWR2aXNvcnkgYW5kIG5vdCBmdW5kYW1lbnRhbGx5IGNoYW5nZSBp bnRlcnByZXRhdGlvbiBvZiB0aGUgcGFja2V0Lg0KPiBIYWQgdGhlIHJlcXVpcmVtZW50IGluIFZY TEFOIGJlZW4gdGhhdCBwYWNrZXRzIHdpdGggdW5rbm93biBiaXRzIHNldA0KPiBiZSBkcm9wcGVk LCB0aGVuIGFkZGluZyBQLWJpdCBhbmQgTy1iaXQgY291bGQgaGF2ZSBiZWVuIGRvbmUgd2l0aA0K PiBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gVGhpcyBtaWdodCBiZSBhIHJlYXNvbmFibGUgcmVx dWlyZW1lbnQgdG8NCj4gY29uc2lkZXIgaWYgbmV3IHByb3RvY29sIChpLmUuIG5ldyBwb3J0IG51 bWJlcikgaXMgdW5kZXJ0YWtlbi4NCj4NCj4gVGhhbmtzLA0KPiBUb20NCj4NCj4+IEFuZCBpZiAq aXQgd2FzIGFncmVlZCogb24gdG8gdXNlIGRpZmZlcmVudCBVRFAgcG9ydCBudW1iZXJzIChsaWtl IHRoZSB3YXkgTElTUCBkaWQgaXQgZm9yIEwyIHZlcnN1cyBMMyBwYWNrZXQgZW5jYXBzdWxhdGlv biksIHdlIHdvdWxkbid0IG5lZWQgdGhlIFAtYml0IGF0IGFsbC4gQnV0IHRoZXJlIHdhcyBwdXNo IGJhY2sgKGJ5IHNvbWVib2R5KSB0byBub3QgYWxsb2NhdGUgYW5vdGhlciBwb3J0IGZvciBWWExB Tiwgc28gdGhlIGRlbXV4IHdhcyBmb3JjZWQgdG8gYmUgaW4gdGhlIFZYTEFOIGhlYWRlci4NCj4+ DQo+PiBBbmQgaXMgYWxzbyB0aGUgcmVhc29uIHRoaXMgYmFnZ2FnZSBpcyBiZWluZyBjYXJyaWVk IG92ZXIgdGhlIExJU1Agd2hlbiBpdCByZWFsbHkgaXNuJ3QgbmVlZGVkLg0KPj4NCj4+PiAzLiBU cnVlLCB0aGUgoa5Qoa8gYml0IGlzIG5vdCBuZWVkZWQgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp dHksIGJ1dCBJoa9tIG5vdCBhZ2FpbnN0IGl0IGlmIHRoZXJlIGlzIHZhbHVlIHRvIG1ha2UgaXQg Y29uc2lzdGVudCB3aXRoIHRoZSBMSVNQLUdQRSBoZWFkZXIuDQo+Pg0KPj4gVGhlcmUgaXMgbm8g aW5jcmVtZW50YWwgYmVuZWZpdCB0byB1c2UgdGhlIFAtYml0IGZvciBMSVNQLiBXZSBoYWQgYSBz b2x1dGlvbiBidXQgYmVjYXVzZSBvZiB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSBubyBuZXcgcG9y dCBmb3IgVlhMQU4sIExJU1AgaXMgYWZmZWN0ZWQuDQo+Pg0KPj4gSnVzdCBhbm90aGVyIGV4YW1w bGUgaG93IHRoZSB3b3JraW5nIGdyb3VwIGlzIHB1dHRpbmcgZWZmb3J0IGludG8gdGhpbmdzIHRo YXQgY3JlYXRlcyBtb3JlIHdvcmsgYnV0IG5vIGJlbmVmaXQuIERvbid0IGdldCBtZSB3cm9uZywg dGhlIGNpc2NvIGd1eXMgZGlkIHRoaXMgKHRoZSBWWExBTiBhbmQgTElTUCBzYW1lIHBvc2l0aW9u IGZvciBQLWJpdCkgZm9yIGNvbnNpc3RlbmN5LCBhbmQgdGhleSBzaG91bGQgYmUgYXBwbGF1ZGVk IGZvciB0aGF0LiBCdXQgaWYgVlhMQU4gY291bGQgaGF2ZSBhbm90aGVyIHBvcnQgbnVtYmVyIGFz c2lnbmVkIGZvciAib3RoZXIgcHJvdG9jb2xzIiwgbWF5YmUgdGhlIFZYTEFOLUdQRSB3b3VsZCBs b29rIHNvIG11Y2ggZGlmZmVyZW50Lg0KPj4NCj4+IFNvbWV0aGluZyB0byB0aGluayBhYm91dCBh cyB0aGUgd29ya2luZyBncm91cCBub3cgaGFzIG5ldyBwcm9kdWN0aXZpdHkgbWVudGFsaXR5Lg0K Pj4NCj4+IERpbm8NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4+IG52bzNAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw== From nobody Mon Jul 28 06:15:47 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CE31A01C6; Mon, 28 Jul 2014 06:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 GgMSDyPGhkXf; Mon, 28 Jul 2014 06:15:40 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5101A0059; Mon, 28 Jul 2014 06:15:40 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id lx4so6636951iec.3 for ; Mon, 28 Jul 2014 06:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P7CMWFUw+1DqD0c9AthcYZXNfzI2F5H16tePyhpEAzk=; b=fUJ9N2EKBNOX1pRHvrIz9fszC+bIlvXdFmqmp2yijuHeqGhif2uS+/8JqNbnHMrf47 0n2fBDXB2/eOZnWI86ptnw9G8g+XTp1JU4arlOwtGJ8veJxQeKlt62Ru/n0NF8ZpI6/U ozYWJLRteMpHyzcTw24+7Ublf73pFNMuZT4K3UHA/jpYvMLfgbKXxcO93YO8RpyLQebE IX6aGM1EWkeLgGqDKQi+6v+4bEaw3Ijay2nt5YAs1OzFpRMER/XxXgXJijdBb0UXP5xi VrqdH/mptsZqbmILV6RobVsgMBIzZ3KH72vybVXJCFIGCzEy6OCvKEdPqAEP5ee1Q/kX 6qiQ== X-Received: by 10.42.208.70 with SMTP id gb6mr4611533icb.89.1406553339502; Mon, 28 Jul 2014 06:15:39 -0700 (PDT) Received: from [10.152.209.141] (mobile-166-147-102-232.mycingular.net. [166.147.102.232]) by mx.google.com with ESMTPSA id i6sm26719947igu.15.2014.07.28.06.15.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 06:15:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Mon, 28 Jul 2014 08:15:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> To: Haoweiguo Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/hPCIJ1f7MYCR5kGS06_-ozxSWvo Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] =?utf-8?b?562U5aSNOiAgQ29tbWVudHMgb24gaHR0cDovL3Rvb2xzLmll?= =?utf-8?q?tf=2Eorg/html/draft-quinn-vxlan-gpe-03?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:15:44 -0000 > On Jul 28, 2014, at 7:24 AM, Haoweiguo wrote: >=20 > About backward compatibility, i also agree with Dino. VXLAN-GPE should foc= us on the VXLAN-GPE header and requires the assignment of a new UDP port, t= he data format don't need consider backward compatibility with VXLAN header.= I I want to make it clear that supporting backward compatibility is very impor= tant since VXLAN-port-4789 is supported in various chips already.=20 Dino From nobody Mon Jul 28 06:55:57 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831C11B2812; Mon, 28 Jul 2014 06:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.348 X-Spam-Level: ** X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MP-yAGT4kVs3; Mon, 28 Jul 2014 06:55:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8BE1A03FD; Mon, 28 Jul 2014 06:55:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHR11598; Mon, 28 Jul 2014 13:55:52 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Jul 2014 14:55:51 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 28 Jul 2014 21:55:47 +0800 From: Haoweiguo To: Dino Farinacci Thread-Topic: =?gb2312?B?tPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0dHA6Ly90b29scy5pZXRmLm9y?= =?gb2312?Q?g/html/draft-quinn-vxlan-gpe-03?= Thread-Index: AQHPqkzAsneDBkHiT0W0YABoAmZP/5u1ZM/Q//+MiICAAIxMcg== Date: Mon, 28 Jul 2014 13:55:46 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> , <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> In-Reply-To: <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.2.229] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/jTws7u5Fk32UpLgVZPDAnDrHtRA Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: [nvo3] =?gb2312?b?tPC4tDogtPC4tDogIENvbW1lbnRzIG9uIGh0dHA6Ly90?= =?gb2312?b?b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:55:55 -0000 SGkgRGlubywNClNvcnJ5LCBpIG1pc3VuZGVyc3Rvb2QgeW91LiBJIHRoaW5rIFZYTEFOLUdQRSBj YW4gZGVmaW5lIGEgbmV3IFVEUCBwb3J0IGFuZCBhIG5ldyBkYXRhIGZvcm1hdCwgUCBiaXQgaW4g VlhMQU4tR1BFIHNlZW1zIHRvIGhhdmUgbm8gYW55IHZhbHVlLiBBcyBmb3IgYmFzaWMgaW50ZXIt c3VibmV0IGxheWVyIDMgY29tbXVuaWNhdGlvbiBhbmQgaW50cmEtc3VibmV0IGxheWVyIDIgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIE5WRXMsIGN1cnJlbnQgTlZHUkUsIFZYTEFOIGFuZCBMSVNQIGhh dmUgYWxyZWFkeSBzdXBwb3J0ZWQsIE5WR1JFLFZYTEFOLExJU1AgYW5kIFZYTEFOLUdQRSBjYW4g YmUgaHlicmlkIHVzZWQgdG8gZm9ybSBhIE5WTzMgbmV0d29yayBpZiBvbmx5IGJhc2ljIGxheWVy IDMgYW5kIGxheWVyIDIgZm9yd2FyZGluZyBwcm9jZXNzIGV4aXN0cy4gQXMgZm9yIHNvbWUgZXh0 cmEgZnVuY3Rpb25zIG9mIE9BTSwgc2VydmljZSBjaGFpbmluZyxhbmQgZXRjLCAgb25seSBWWExB Ti1HUEUgY2FuIHN1cHBvcnQsIHB1cmUgVlhMQU4tR1BFIG5ldHdvcmsgc2hvdWxkIGJlIHVzZWQg aW4gdGhlc2UgY2FzZXMuDQpUaGFua3MNCndlaWd1bw0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCreivP7IyzogRGlubyBGYXJpbmFjY2kgW2ZhcmluYWNjaUBn bWFpbC5jb21dDQq3osvNyrG85DogMjAxNMTqN9TCMjjI1SAyMToxNQ0KytW8/sjLOiBIYW93ZWln dW8NCrOty806IFRvbSBIZXJiZXJ0OyBEYXZpZCBNZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1Ag bWFpbGluZyBsaXN0IGxpc3QNCtb3zOI6IFJlOiC08Li0OiBbbnZvM10gQ29tbWVudHMgb24gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQoNCj4gT24g SnVsIDI4LCAyMDE0LCBhdCA3OjI0IEFNLCBIYW93ZWlndW8gPGhhb3dlaWd1b0BodWF3ZWkuY29t PiB3cm90ZToNCj4NCj4gQWJvdXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaSBhbHNvIGFncmVl IHdpdGggRGluby4gVlhMQU4tR1BFIHNob3VsZCBmb2N1cyBvbiAgdGhlIFZYTEFOLUdQRSBoZWFk ZXIgYW5kIHJlcXVpcmVzIHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUCBwb3J0LCB0aGUgZGF0 YSBmb3JtYXQgZG9uJ3QgbmVlZCBjb25zaWRlciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGgg VlhMQU4gaGVhZGVyLiBJDQoNCkkgd2FudCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgc3VwcG9ydGlu ZyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIHZlcnkgaW1wb3J0YW50IHNpbmNlIFZYTEFOLXBv cnQtNDc4OSBpcyBzdXBwb3J0ZWQgaW4gdmFyaW91cyBjaGlwcyBhbHJlYWR5Lg0KDQpEaW5v From nobody Mon Jul 28 07:18:28 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5CF1B282E; Mon, 28 Jul 2014 07:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=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 CkbJQW64_dKh; Mon, 28 Jul 2014 07:18:24 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D416E1B2829; Mon, 28 Jul 2014 07:18:23 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so6465922ieb.7 for ; Mon, 28 Jul 2014 07:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TelHGi+z3MYwTP71GPq/gvU34oupiOw93caMBUl/vLs=; b=y8OqsxrRY//i6KTsavOfQ3gF8jYJD01xAbSnPHVb92ZHCtiXoXVa8sEp/w3iKAHLx/ Po6TGfXzvKByo2zrQ7auRMf3hra8ggKrzdEK+la5PXpZ3x6H3cQ1WfOK16uV7Sv4NP3X FjuQ1wQoVYhA6JIBHBn8Bbcc33xDuiHKgAVpJVGFjXO+AxMb2K0Y6Uxmtxs7/OG5Jriy vfgPXOQSqkB1S5eSBi/ny6ln9DPGG0o18Papx2pAzHcl4Jh/1R6le/tWue/nyUCRoLNq PZtCDnDlUy7ZNvzyJbCyWDHABYeHOUNhX0okeaHwCnty51K/+XTHUbhidA9intyRSu0C 1u4A== X-Received: by 10.50.8.6 with SMTP id n6mr15025759iga.43.1406557103293; Mon, 28 Jul 2014 07:18:23 -0700 (PDT) Received: from [172.19.131.148] ([12.130.116.26]) by mx.google.com with ESMTPSA id tp2sm27211960igb.7.2014.07.28.07.18.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 07:18:22 -0700 (PDT) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Mon, 28 Jul 2014 07:17:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> , <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> To: Haoweiguo X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/qZJ8syLsRMR3GVd97OEjpvZmuqQ Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:18:25 -0000 > Hi Dino, > Sorry, i misunderstood you. I think VXLAN-GPE can define a new UDP = port and a new data format, P bit=20 No worries.=20 > in VXLAN-GPE seems to have no any value. As for basic inter-subnet = layer 3 communication and intra-subnet layer 2 communication between = NVEs, current NVGRE, VXLAN and LISP have already supported,=20 VXLAN supports L2 overlays since its goal is to extend subnets. LISP = supports L3 overlays so it assumes subnets are local (to the xTR) just = like in a routed network. NVGRE can be a combo. > NVGRE,VXLAN,LISP and VXLAN-GPE can be hybrid used to form a NVO3 = network if only basic layer 3 and=20 There is motivation to extend an encapsulation header (which is called = VXLAN-GPE) so it can support, most importantly NSH. That change also = gives VXLAN to support encapsulating layer-2 IPv4 and IPv6, which is = duplicate functionality of LISP. But the headers are so similar, it = really doens't matter. However, the P-bit is not needed for anything new in LISP and the = OAM-bit is not needed in LISP since LISP has different UDP port number = (4342) for control-packets. VXLAN does not have a well defined control = protocol so the data-plane has to escape out control-plane pakcets where = the first one is this new OAM message. > layer 2 forwarding process exists. As for some extra functions of OAM, = service chaining,and etc, only VXLAN-GPE can support, pure VXLAN-GPE = network should be used in these cases. > Thanks > weiguo Right, agree. Dino >=20 >=20 > ________________________________________ > =B7=A2=BC=FE=C8=CB: Dino Farinacci [farinacci@gmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C228=C8=D5 21:15 > =CA=D5=BC=FE=C8=CB: Haoweiguo > =B3=AD=CB=CD: Tom Herbert; David Melman; nvo3@ietf.org; LISP mailing = list list > =D6=F7=CC=E2: Re: =B4=F0=B8=B4: [nvo3] Comments on = http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >=20 >> On Jul 28, 2014, at 7:24 AM, Haoweiguo wrote: >>=20 >> About backward compatibility, i also agree with Dino. VXLAN-GPE = should focus on the VXLAN-GPE header and requires the assignment of a = new UDP port, the data format don't need consider backward compatibility = with VXLAN header. I >=20 > I want to make it clear that supporting backward compatibility is very = important since VXLAN-port-4789 is supported in various chips already. >=20 > Dino From nobody Mon Jul 28 08:08:50 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A58C1A0310 for ; Mon, 28 Jul 2014 08:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 jbcZqiLuTFh8 for ; Mon, 28 Jul 2014 08:08:33 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5A81B2866 for ; Mon, 28 Jul 2014 08:08:32 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id h15so3790668igd.17 for ; Mon, 28 Jul 2014 08:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EVuE9LFU3uq299dzh3R8IvW6z6Rx8gpwx/RvpJqayBo=; b=JLVUsl2RkT3orXbYkqhmjtTSK42QsrCmujQlHsO+hJUqQyY2wPI6aru1lx6JrlE3DR tUcmfuanZFFKbof+HQhYVRb9GzjazEYFpRFtK30bXc6UQYMrZSvmBC3Bo/gfOC4aau0B vsgZYrRaNJeQp+2wf4YI51INrUbXUSWVhwvL8OiVkDnwJjwsANE1Ebg3IxFUTIAuNM0i VsulRD4JHDCJvPDCl+8lv93cvYetTrrtZlNvJWsueDQwb5dRu0OrHDrpk3gRgKUR5Wsm Afc12mv/xhMQqmUvzZAURnJfkeUcJW6ga89+X0C+JcF+EHgHPU6M888PGC2ZY3IYeKr6 yCUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EVuE9LFU3uq299dzh3R8IvW6z6Rx8gpwx/RvpJqayBo=; b=Ipo3Er9n/rdazfnzwd9FOqG/LKoFrFo8HTZj9E9VU5K78tbN13hYaqBXNTPia8CxnW kKDWBGLuNE9cDLplTOaKdjXS8eOpjTKZivbZQFvji8JV52qczXaC+oZ0OnzSpc3NUKKp cNs+l/uFz8twyXlJ1TmNE2xtOzcwA/Qw+TFL2Rwwgd03eZvAmVV43cY4oi5cCouJKWph ogW4xcvN9nTe8vs0VSxuJcen6vYeb07wKorJJ8DLjuP6awlBzMhg7DaLbj3ERRaQj+b9 xTacDWAzjrhFIXzWed+veT/sNrCZGSDXLNNu7PO6zJZFVO/sxIZofmgtZFbkq+7h4+vF O78g== X-Gm-Message-State: ALoCoQlxkm5as38nFiCwEOc1rmzCNlDXROKtZMQFTJpfWlLxVjQjDNpHmuefNMXcDDasWBq5eixL MIME-Version: 1.0 X-Received: by 10.42.93.84 with SMTP id w20mr44736139icm.49.1406560111533; Mon, 28 Jul 2014 08:08:31 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Mon, 28 Jul 2014 08:08:31 -0700 (PDT) In-Reply-To: <20140727235848276183.21b2fe35@sniff.de> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> Date: Mon, 28 Jul 2014 08:08:31 -0700 Message-ID: From: Tom Herbert To: Marc Binderberger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/ZkscFIHtLkr7r-jjBEk1uWTHWSg Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Dino Farinacci Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:08:35 -0000 >> Allowing the reserved bits in the header to be ignored on receive >> limits the usefulness in that new bits that are defined can only be >> advisory and not fundamentally change interpretation of the packet. > > I agree with your statement in the 2nd half but not your opinion about th= e > usefulness. Don't see a problem here, LISP is a good example how ignoring > unknown flags works well. > How so? Adding protocol field to LISP-gpe has the same backwards compatibility problem as VXLAN-gpe, but is resolving it in a different way. The addition of the P-bit relies on some (presumably) out of band mechanism to ensure protocol compatibility. From the LISP-gpe draft: "A LISP-gpe router MUST not encapsulate non-IP packets to a LISP router. A method for determining the capabilities of a LISP router (gpe or "legacy") is out of the scope of this draft." Thanks, Tom > > Regards, Marc > > > > On Sun, 27 Jul 2014 17:28:01 -0700, Tom Herbert wrote: >> On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci wr= ote: >>>> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and >>>> requires the assignment of a new UDP port. The fact that the VXLAN-G= PE >>>> header closely resembles VXLAN may be convenient for implementers, but >>>> this protocol by definition is not backward compatible with VXLAN. >>> >>> If you do that then it will be harder for VXLAN-GPE systems to >>> interoperate with a VXLAN systems. Because a VXLAN-GPE system will need= to >>> open and maintain 2 UDP sockets. And an implementaiton will have to be >>> careful to not set the P-bit for the VXLAN socket or clear the P-bit fo= r >>> VXLAN-GPE socket. This is all completely unnecessary and one way or the >>> other should be used. >>> >> I am not sure what you are suggesting. AFAICT there is no backwards >> compatible means to to add the protocol field to VXLAN which is the >> motivation for the new UDP port, which in turn implies a new protocol >> (which also implies an opportunity to add a more general set of >> protocol features like version number and options extensions which are >> also not backwards compatible). Maybe it's possible to break >> compatibility within the protocol and assume that out of band >> mechanisms could negotiate use of P-bit to compensate, but I assume >> there's already quite a bit of VXLAN deployment so that seems pretty >> shaky robustness-wise to me. >> >> It's not just adding the protocol field that would be an issue, even >> adding the OAM bit to VXLAN would be problematic. Per VXLAN spec >> unspecified flag bits are ignored on receive, so if the OAM bit were >> subsequently defined in VXLAN it will be ignored by existing >> implementations and these packets will be processed normally-- this >> seems to be incompatible with the proposed VXLAN-gpe requirement that >> "When the O bit is set to 1, the packet is an OAM packet and OAM >> processing MUST occur." (btw 'OAM processing' is awfully ambiguous to >> be a MUST here IMO). >> >> Allowing the reserved bits in the header to be ignored on receive >> limits the usefulness in that new bits that are defined can only be >> advisory and not fundamentally change interpretation of the packet. >> Had the requirement in VXLAN been that packets with unknown bits set >> be dropped, then adding P-bit and O-bit could have been done with >> backwards compatibility. This might be a reasonable requirement to >> consider if new protocol (i.e. new port number) is undertaken. >> >> Thanks, >> Tom >> >>> And if *it was agreed* on to use different UDP port numbers (like the w= ay >>> LISP did it for L2 versus L3 packet encapsulation), we wouldn't need th= e >>> P-bit at all. But there was push back (by somebody) to not allocate >>> another port for VXLAN, so the demux was forced to be in the VXLAN head= er. >>> >>> And is also the reason this baggage is being carried over the LISP when= it >>> really isn't needed. >>> >>>> 3. True, the =E2=80=98P=E2=80=99 bit is not needed for backward compat= ibility, but I=E2=80=99m >>>> not against it if there is value to make it consistent with the LISP-G= PE >>>> header. >>> >>> There is no incremental benefit to use the P-bit for LISP. We had a >>> solution but because of the requirement to have no new port for VXLAN, >>> LISP is affected. >>> >>> Just another example how the working group is putting effort into thing= s >>> that creates more work but no benefit. Don't get me wrong, the cisco gu= ys >>> did this (the VXLAN and LISP same position for P-bit) for consistency, = and >>> they should be applauded for that. But if VXLAN could have another port >>> number assigned for "other protocols", maybe the VXLAN-GPE would look s= o >>> much different. >>> >>> Something to think about as the working group now has new productivity >>> mentality. >>> >>> Dino >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From nobody Mon Jul 28 10:22:15 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9294C1A0326; Mon, 28 Jul 2014 10:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sPPQwk76ve2u; Mon, 28 Jul 2014 10:22:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E818F1A04B1; Mon, 28 Jul 2014 10:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=424; q=dns/txt; s=iport; t=1406568123; x=1407777723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8tplnHoalXoOJL5H3k/MOiEDZRFhwXtqz+fRAu6Ua1I=; b=WoeE/uzscFPSoej2o6Bub0cs7Sb9zPQtnZI79H24kbHmL6gKt1xiTmQW Z3uPNjqHbmrALsJFiuXdv4GW8+L2N/jQ+qrnMVIuU0nERZuaEAytT984O xxhRku1BJiy5wljo5Mju2Lqe/ofhi8/8rPKbNq1pYsrOuXhAZZY5TCuMr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANeF1lOtJA2G/2dsb2JhbABZgw5SVwTMCodFAYEQFneEBAEBAwE6MgoDEAIBCDYQIRElAgQOBYguAwkIDbcZDYcHF40fgXozB4MvgRsBBJlHggWBUoxXhiODSWyBRQ X-IronPort-AV: E=Sophos;i="5.01,750,1400025600"; d="scan'208";a="343378660" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jul 2014 17:22:02 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6SHM2Rj024953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 17:22:02 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 12:22:01 -0500 From: "Darrel Lewis (darlewis)" To: Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqohxFDuESdVPfU+MWLGrMK03OQ== Date: Mon, 28 Jul 2014 17:22:01 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <3CAE1D58-3277-4B8E-A4AF-F52CC81192D6@gmail.com> In-Reply-To: <3CAE1D58-3277-4B8E-A4AF-F52CC81192D6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.253.182] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/NTAaEDCqOChPMWWQq5dprhAwzUI Cc: "Darrel Lewis \(darlewis\)" , Marc Binderberger , LISP mailing list list , "nvo3@ietf.org" , David Melman , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 17:22:08 -0000 On Jul 28, 2014, at 3:14 AM, Dino Farinacci wrote: >> The point Dino makes is (I think): is there really a gain to "re-invent"= =20 >> VxLAN and LISP data encapsulation? And it might be actually easier to=20 >> implement and test separate encodings instead of the more complex combin= ed=20 >> header in VxLAN-gpe. >=20 > Exactly.=20 And the authors believe there is value. -Darrel= From nobody Mon Jul 28 11:10:04 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F43C1A0218 for ; Mon, 28 Jul 2014 11:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 4_Ke63_cWXnc for ; Mon, 28 Jul 2014 11:09:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F161A083D for ; Mon, 28 Jul 2014 11:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6751; q=dns/txt; s=iport; t=1406570991; x=1407780591; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=u+21L06DJYsK9UcJlcR/GgEdx08izPpN+wPbMazZ4JM=; b=G2V21oneWZ32Y1PgfX6/hSHaLiihINZkhP3BqRj+unqpDqk0FSl5ZxBk PdIDDg57q1/czvfDPBv2YmFR3mgi9QcKfEb53aB53PMrE8PrBDzgQ0EdL p3GfgRviUYZNbJOKBP6znaFXm3c7mNuSM0WYWdMmEc6XUeZ5B6XzlwiO9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJuQ1lOtJA2D/2dsb2JhbABZgw5SV4IvSckMCodFAYERFneEBAEBBAEBAQkXDwEFLwcKEQkCGAICBRYLAgIJAwIBAgEPBjATBgIBAReIEwMRDYpdnDCPdg2HBxeBLItzgjSCeYFRAQSKcY5WggWBUoVMhwuGI4NpHS8 X-IronPort-AV: E=Sophos;i="5.01,750,1400025600"; d="scan'208";a="64645687" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 28 Jul 2014 18:09:50 +0000 Received: from [10.155.136.156] (dhcp-10-155-136-156.cisco.com [10.155.136.156]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6SI9mam010344 for ; Mon, 28 Jul 2014 18:09:48 GMT Message-ID: <53D691EB.8000402@cisco.com> Date: Mon, 28 Jul 2014 11:09:47 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: nvo3@ietf.org References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/da5mci34Nz3Ao8g1vEwXGg-HYtg Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 18:10:00 -0000 On 7/28/14, 8:08 AM, Tom Herbert wrote: >>> Allowing the reserved bits in the header to be ignored on receive >>> limits the usefulness in that new bits that are defined can only be >>> advisory and not fundamentally change interpretation of the packet. >> I agree with your statement in the 2nd half but not your opinion about the >> usefulness. Don't see a problem here, LISP is a good example how ignoring >> unknown flags works well. >> > How so? Adding protocol field to LISP-gpe has the same backwards > compatibility problem as VXLAN-gpe, but is resolving it in a different > way. The addition of the P-bit relies on some (presumably) out of band > mechanism to ensure protocol compatibility. From the LISP-gpe draft: > > "A LISP-gpe router MUST not encapsulate non-IP packets to a LISP > router. A method for determining the capabilities of a LISP router > (gpe or "legacy") is out of the scope of this draft." Tom, with the LISP control plane (as with many other control planes) it's trivial to encode the capability of the receiving end of a tunnel (ETR) in the mapping itself. When the sender (ITR) encapsulates the packet it can then "choose" the appropriate data path encoding. The P bit helps taking advantage of similarities between LISP-GPE and LISP, and would allow an implementation to send LISP-GPE packets (P=1) containing IPv4/v6 encapsulated packets to a legacy LISP router, on the UDP port 4341 (LISP). The legacy LISP router, per LISP specification, will ignore the P bit and the next protocol field (as long as N,E,V = 0). This allows to transition LISP fabrics to LISP-GPE without the need for a new UDP port. Given we have quite a large installed base of LISP devices, this is one of the design goals of the LISP-GPE protocol. The same applies to VXLAN-GPE, when you use a control plane with the characteristics above (e.g. LISP). Note that both LISP and VXLAN define reserved bits as set to 0 in tx, ignore in rx. Since the GPE drafts are about data plane, the method for determining the capabilities of the receiving end (GPE or "legacy") is out of the scope of those drafts (will certainly be in scope of control plane drafts, though). Thanks, Fabio > Thanks, > Tom > >> Regards, Marc >> >> >> >> On Sun, 27 Jul 2014 17:28:01 -0700, Tom Herbert wrote: >>> On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci wrote: >>>>> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and >>>>> requires the assignment of a new UDP port. The fact that the VXLAN-GPE >>>>> header closely resembles VXLAN may be convenient for implementers, but >>>>> this protocol by definition is not backward compatible with VXLAN. >>>> If you do that then it will be harder for VXLAN-GPE systems to >>>> interoperate with a VXLAN systems. Because a VXLAN-GPE system will need to >>>> open and maintain 2 UDP sockets. And an implementaiton will have to be >>>> careful to not set the P-bit for the VXLAN socket or clear the P-bit for >>>> VXLAN-GPE socket. This is all completely unnecessary and one way or the >>>> other should be used. >>>> >>> I am not sure what you are suggesting. AFAICT there is no backwards >>> compatible means to to add the protocol field to VXLAN which is the >>> motivation for the new UDP port, which in turn implies a new protocol >>> (which also implies an opportunity to add a more general set of >>> protocol features like version number and options extensions which are >>> also not backwards compatible). Maybe it's possible to break >>> compatibility within the protocol and assume that out of band >>> mechanisms could negotiate use of P-bit to compensate, but I assume >>> there's already quite a bit of VXLAN deployment so that seems pretty >>> shaky robustness-wise to me. >>> >>> It's not just adding the protocol field that would be an issue, even >>> adding the OAM bit to VXLAN would be problematic. Per VXLAN spec >>> unspecified flag bits are ignored on receive, so if the OAM bit were >>> subsequently defined in VXLAN it will be ignored by existing >>> implementations and these packets will be processed normally-- this >>> seems to be incompatible with the proposed VXLAN-gpe requirement that >>> "When the O bit is set to 1, the packet is an OAM packet and OAM >>> processing MUST occur." (btw 'OAM processing' is awfully ambiguous to >>> be a MUST here IMO). >>> >>> Allowing the reserved bits in the header to be ignored on receive >>> limits the usefulness in that new bits that are defined can only be >>> advisory and not fundamentally change interpretation of the packet. >>> Had the requirement in VXLAN been that packets with unknown bits set >>> be dropped, then adding P-bit and O-bit could have been done with >>> backwards compatibility. This might be a reasonable requirement to >>> consider if new protocol (i.e. new port number) is undertaken. >>> >>> Thanks, >>> Tom >>> >>>> And if *it was agreed* on to use different UDP port numbers (like the way >>>> LISP did it for L2 versus L3 packet encapsulation), we wouldn't need the >>>> P-bit at all. But there was push back (by somebody) to not allocate >>>> another port for VXLAN, so the demux was forced to be in the VXLAN header. >>>> >>>> And is also the reason this baggage is being carried over the LISP when it >>>> really isn't needed. >>>> >>>>> 3. True, the ‘P’ bit is not needed for backward compatibility, but I’m >>>>> not against it if there is value to make it consistent with the LISP-GPE >>>>> header. >>>> There is no incremental benefit to use the P-bit for LISP. We had a >>>> solution but because of the requirement to have no new port for VXLAN, >>>> LISP is affected. >>>> >>>> Just another example how the working group is putting effort into things >>>> that creates more work but no benefit. Don't get me wrong, the cisco guys >>>> did this (the VXLAN and LISP same position for P-bit) for consistency, and >>>> they should be applauded for that. But if VXLAN could have another port >>>> number assigned for "other protocols", maybe the VXLAN-GPE would look so >>>> much different. >>>> >>>> Something to think about as the working group now has new productivity >>>> mentality. >>>> >>>> Dino >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Mon Jul 28 11:14:14 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD1B1A0ABD for ; Mon, 28 Jul 2014 11:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 xbEp8IuY7eDv for ; Mon, 28 Jul 2014 11:14:08 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BD91A0AC1 for ; Mon, 28 Jul 2014 11:13:58 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so10303942pdj.40 for ; Mon, 28 Jul 2014 11:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h3XR6nhBML9vdCd8AXD0XaVs4HLQZn/QWvWHqDUS+ME=; b=lhZdt9+HXzgJ18yy+A771ywzcmI88kXF31eMEi6NQ4jKEiFSYqW/iUIp8WickFEE+E 4zgP955YABX0v6tlQVurbDJDjWCEwnb8JxI6oDYp3WvzyrUwzm5cleCSFiY313TvnWgi 02bZu10xvXjnoFR+USM4+Hxc9x0IwkC8p/M/Gy14w/UVF3Bs2g2fs/0uhnymSDIEH3lQ ESgY6aZ4w6G0bp3cNZdqkLhScb2BzWnKxrnYBVpF2HdRsQ3PWrI+T3P8pCmozE3fA6t6 sBR0WUeMWHBngXJn0pBZN7OinDOekwjKgxfuhI1/23HG+azI7rw0w3NhzafbGzn/Y7qb O3Cg== X-Received: by 10.68.221.161 with SMTP id qf1mr39984784pbc.45.1406571237934; Mon, 28 Jul 2014 11:13:57 -0700 (PDT) Received: from [10.175.30.108] (mobile-166-137-176-187.mycingular.net. [166.137.176.187]) by mx.google.com with ESMTPSA id ug1sm69076046pac.9.2014.07.28.11.13.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 11:13:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: <53D691EB.8000402@cisco.com> Date: Mon, 28 Jul 2014 11:13:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <53D691EB.8000402@cisco.com> To: Fabio Maino Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/u6XY3-pUIUvgzBFhsqGWIAw6qgg Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 18:14:10 -0000 > On Jul 28, 2014, at 11:09 AM, Fabio Maino wrote: >=20 > The P bit helps taking advantage of similarities between LISP-GPE and LISP= , and would allow an implementation to send LISP-GPE packets (P=3D1) contain= ing IPv4/v6 encapsulated packets to a legacy LISP router, on the UDP port 43= 41 Fabio - this could be misleading to make people think without the P-bit that= you could not encapsulate IPv4/IPv6/MAC. And we all now we support that in L= ISP today.=20 Dino= From nobody Mon Jul 28 11:39:46 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CAA1A0097; Mon, 28 Jul 2014 11:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 lLBs3HdeoipO; Mon, 28 Jul 2014 11:39:42 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0241A03C2; Mon, 28 Jul 2014 11:39:42 -0700 (PDT) Received: by door.sniff.de (Postfix, from userid 1000) id 3A03D2AA11; Mon, 28 Jul 2014 18:39:40 +0000 (GMT) Date: Mon, 28 Jul 2014 18:39:40 +0000 From: Marc Binderberger To: "Darrel Lewis (darlewis)" Message-ID: <20140728183939.A25626@door.sniff.de> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <3CAE1D58-3277-4B8E-A4AF-F52CC81192D6@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from darlewis@cisco.com on Mon, Jul 28, 2014 at 05:22:01PM +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/u8m-sUc-hGELJEq-Etqb6Hi7MA8 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Dino Farinacci , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 18:39:43 -0000 Hello Darrel, > And the authors believe there is value. otherwise you wouldn't have written it down ;-) That's what this discussion is (also) about: learning what are the pros and cons and how to weight them. Regards, Marc From nobody Mon Jul 28 12:04:35 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C7E1B27DC for ; Mon, 28 Jul 2014 12:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 ayEl-nrKYlXl for ; Mon, 28 Jul 2014 12:04:31 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2BD1ABB22 for ; Mon, 28 Jul 2014 12:04:30 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so7197921ier.27 for ; Mon, 28 Jul 2014 12:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=I0E2EA5F6Pl5Ihmo+c6Spw62YpZn/p+GAMZQydvz1mo=; b=FvAgs7YU+2EGCEsdXWd1zdf8hHEHVWNgQqj9Wqc/bbEAoV38yYWUIkyRpDA98Oe4Yd 8VestBmPy06//a6nIWzwEk/PZeN2NrCAsBT0DLslw+e2BNs9CNV+D7iu9S/u0eoxOHsX AJmHooSrBGCc+gDIRZ3MNnD1tUQGNfufvVxIimmPTVcQygE/GPHTCHOprrK+W12GkExC QBT76ShYOsNrh9+iPDDdSS4sKtWt6RQYgq0133jYjn4QKSk1d1TJXl1j4s/PLMw882Ua c/Ig5p/s51v5h6mjJbI8faMbJeeITe4SX1Fiwg9g24+QJrvpW+YcJt42RjtVf/RnobtE 0Ljw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I0E2EA5F6Pl5Ihmo+c6Spw62YpZn/p+GAMZQydvz1mo=; b=j+HwGR3NVFVE93ZslbpLQh5CYOiZheGQlPv7BLA0uma2V/RleOLmnDtnkZ2ZZ8jBTB cDKOX+ZcAMSe90AJmMmkLV56CweXcErlSwHe942/1ym5k4vkjz6ijM3UlXX8gDzj8MkF mvJRGcGrW99ggM8p14DMJBUe9TK/TZWrrGPj8WQGL4/+K8TKholehKICHPwJCVLcEfDM xfFlGX2G7siotayzk1YGg0ogdFe6dJGusBxbQyRooO7y6uPqeBUcSgyVqIY1thZ0KY34 IjoSBUcXOdCS9M98CfwBZd9eJe9yY+5l+sqgN3KXrUzhIR7Av63MNY738OUD9x4+ES80 mAVg== X-Gm-Message-State: ALoCoQkLsK2WHuLgnfn4/CdWxmySGI7c8bo929rIiQXSnpXz6hdvjDlHb3M0PuF1keyhPmEGlmTx MIME-Version: 1.0 X-Received: by 10.42.93.84 with SMTP id w20mr46500571icm.49.1406574270378; Mon, 28 Jul 2014 12:04:30 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Mon, 28 Jul 2014 12:04:30 -0700 (PDT) In-Reply-To: <53D691EB.8000402@cisco.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <53D691EB.8000402@cisco.com> Date: Mon, 28 Jul 2014 12:04:30 -0700 Message-ID: From: Tom Herbert To: Fabio Maino Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/e1MgdfqUOlTWgt8lX5URXVpaq6I Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:04:33 -0000 > Tom, > with the LISP control plane (as with many other control planes) it's triv= ial > to encode the capability of the receiving end of a tunnel (ETR) in the > mapping itself. When the sender (ITR) encapsulates the packet it can the= n > "choose" the appropriate data path encoding. > > The P bit helps taking advantage of similarities between LISP-GPE and LIS= P, > and would allow an implementation to send LISP-GPE packets (P=3D1) contai= ning > IPv4/v6 encapsulated packets to a legacy LISP router, on the UDP port 434= 1 > (LISP). The legacy LISP router, per LISP specification, will ignore the P > bit and the next protocol field (as long as N,E,V =3D 0). This allows to > transition LISP fabrics to LISP-GPE without the need for a new UDP port. > Given we have quite a large installed base of LISP devices, this is one o= f > the design goals of the LISP-GPE protocol. > > The same applies to VXLAN-GPE, when you use a control plane with the > characteristics above (e.g. LISP). Note that both LISP and VXLAN define > reserved bits as set to 0 in tx, ignore in rx. > > Since the GPE drafts are about data plane, the method for determining the > capabilities of the receiving end (GPE or "legacy") is out of the scope o= f > those drafts (will certainly be in scope of control plane drafts, though)= . If negotiation is available then the precise set of flags can be negotiated, so if an unexpected or unknown flag is received it's obviously invalid and a reasonable recourse is to drop the packet. If negotiation is essential before communication (which so far seems to be true for network virtualization), the set of possible flags (or options) can be constrained a priori so that need to ignore unknown flags would be moot, by design an end host should never receive an unknown flag. By this same rationale, I tend to think the "Critical options" bit is unnecessary in geneve. IMO if a sender took the time to set a flag or an option it must have done that with the intent that the receiver (or someone in the network) will consume it. The caveat to this is that intermediate devices may also need to parse packets but not necessarily participate in the protocol control plane. Consider a stateless firewall that parses LISP packets to filter on encapsulated IP destination address. If the P-bit is implemented in the end hosts, but we've neglected to update all the firewalls in the path-- the packet will be misinterpreted if say the firewall sees a LISP packet with an encapsulated Ethernet frame. In this case, hopefully the firewall will drop the packet, but there's no guarantee of that-- the behavior is non-deterministic. Maintaining compatibility with such devices is a hard problem and might imply constraints on new options that could fundamental change parsing or interpretation of the packet (adding protocol type is a good example case). Thanks, Tom > Thanks, > Fabio > >> Thanks, >> Tom >> >>> Regards, Marc >>> >>> >>> >>> On Sun, 27 Jul 2014 17:28:01 -0700, Tom Herbert wrote: >>>> >>>> On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci >>>> wrote: >>>>>> >>>>>> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and >>>>>> requires the assignment of a new UDP port. The fact that the >>>>>> VXLAN-GPE >>>>>> header closely resembles VXLAN may be convenient for implementers, b= ut >>>>>> this protocol by definition is not backward compatible with VXLAN. >>>>> >>>>> If you do that then it will be harder for VXLAN-GPE systems to >>>>> interoperate with a VXLAN systems. Because a VXLAN-GPE system will ne= ed >>>>> to >>>>> open and maintain 2 UDP sockets. And an implementaiton will have to b= e >>>>> careful to not set the P-bit for the VXLAN socket or clear the P-bit >>>>> for >>>>> VXLAN-GPE socket. This is all completely unnecessary and one way or t= he >>>>> other should be used. >>>>> >>>> I am not sure what you are suggesting. AFAICT there is no backwards >>>> compatible means to to add the protocol field to VXLAN which is the >>>> motivation for the new UDP port, which in turn implies a new protocol >>>> (which also implies an opportunity to add a more general set of >>>> protocol features like version number and options extensions which are >>>> also not backwards compatible). Maybe it's possible to break >>>> compatibility within the protocol and assume that out of band >>>> mechanisms could negotiate use of P-bit to compensate, but I assume >>>> there's already quite a bit of VXLAN deployment so that seems pretty >>>> shaky robustness-wise to me. >>>> >>>> It's not just adding the protocol field that would be an issue, even >>>> adding the OAM bit to VXLAN would be problematic. Per VXLAN spec >>>> unspecified flag bits are ignored on receive, so if the OAM bit were >>>> subsequently defined in VXLAN it will be ignored by existing >>>> implementations and these packets will be processed normally-- this >>>> seems to be incompatible with the proposed VXLAN-gpe requirement that >>>> "When the O bit is set to 1, the packet is an OAM packet and OAM >>>> processing MUST occur." (btw 'OAM processing' is awfully ambiguous to >>>> be a MUST here IMO). >>>> >>>> Allowing the reserved bits in the header to be ignored on receive >>>> limits the usefulness in that new bits that are defined can only be >>>> advisory and not fundamentally change interpretation of the packet. >>>> Had the requirement in VXLAN been that packets with unknown bits set >>>> be dropped, then adding P-bit and O-bit could have been done with >>>> backwards compatibility. This might be a reasonable requirement to >>>> consider if new protocol (i.e. new port number) is undertaken. >>>> >>>> Thanks, >>>> Tom >>>> >>>>> And if *it was agreed* on to use different UDP port numbers (like the >>>>> way >>>>> LISP did it for L2 versus L3 packet encapsulation), we wouldn't need >>>>> the >>>>> P-bit at all. But there was push back (by somebody) to not allocate >>>>> another port for VXLAN, so the demux was forced to be in the VXLAN >>>>> header. >>>>> >>>>> And is also the reason this baggage is being carried over the LISP wh= en >>>>> it >>>>> really isn't needed. >>>>> >>>>>> 3. True, the =E2=80=98P=E2=80=99 bit is not needed for backward comp= atibility, but I=E2=80=99m >>>>>> not against it if there is value to make it consistent with the >>>>>> LISP-GPE >>>>>> header. >>>>> >>>>> There is no incremental benefit to use the P-bit for LISP. We had a >>>>> solution but because of the requirement to have no new port for VXLAN= , >>>>> LISP is affected. >>>>> >>>>> Just another example how the working group is putting effort into >>>>> things >>>>> that creates more work but no benefit. Don't get me wrong, the cisco >>>>> guys >>>>> did this (the VXLAN and LISP same position for P-bit) for consistency= , >>>>> and >>>>> they should be applauded for that. But if VXLAN could have another po= rt >>>>> number assigned for "other protocols", maybe the VXLAN-GPE would look >>>>> so >>>>> much different. >>>>> >>>>> Something to think about as the working group now has new productivit= y >>>>> mentality. >>>>> >>>>> Dino >>>>> >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Mon Jul 28 12:12:24 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901151A017A for ; Mon, 28 Jul 2014 12:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 GQ3ZQB_q8hoi for ; Mon, 28 Jul 2014 12:12:17 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB061B27DC for ; Mon, 28 Jul 2014 12:12:10 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so10397592pdj.12 for ; Mon, 28 Jul 2014 12:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uW2Euqq1uOV3SBp7rtU3VTx59wGQt54swF7wynFKVyI=; b=Bz2YUIwqZyYFWxtCFpumi+/wsmKhKDev4E7jREakPUo0KDK+zxCbMJYgqi+7eBrCeE N1iu8/PlBBxjZS+B9F6TY6u71YNRgWwgTAyqfpQrrz2KxFKFSCGISceLT7t7e5bLc8N/ QPmtmwEzhB1qwmVfbtPzsqZOoPc9a9hHlcGktgWPue2Sc1HHZK6UP4XQlBp8SMDBuMh2 OUq/TERArO3MXPiUCavGs8DKdOU2TLreOydDQBT+pKe3d4oU4/nn83SApttbTSIt8CrH UbHE+Lv7T/b0JureiQtyRjEaWP0cHtss0v8YwD7ko50/DkifcP9s/UdAFeuTVfbO/DeO vszw== X-Received: by 10.70.43.206 with SMTP id y14mr40705905pdl.11.1406574730535; Mon, 28 Jul 2014 12:12:10 -0700 (PDT) Received: from [192.168.1.79] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id o2sm24186691pdf.57.2014.07.28.12.12.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 12:12:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Mon, 28 Jul 2014 12:12:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <98564227-C22C-4AB4-BB71-5E2FE76C10E4@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <53D691EB.8000402@cisco.com> To: Tom Herbert X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/rjXwwXUUPoQrJuJ1zI-YRMsw-aM Cc: Fabio Maino , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:12:22 -0000 > The caveat to this is that intermediate devices may also need to parse > packets but not necessarily participate in the protocol control plane. > Consider a stateless firewall that parses LISP packets to filter on > encapsulated IP destination address. If the P-bit is implemented in > the end hosts, but we've neglected to update all the firewalls in the > path-- the packet will be misinterpreted if say the firewall sees a > LISP packet with an encapsulated Ethernet frame. In this case, > hopefully the firewall will drop the packet, but there's no guarantee > of that-- the behavior is non-deterministic. Maintaining compatibility > with such devices is a hard problem and might imply constraints on new > options that could fundamental change parsing or interpretation of the > packet (adding protocol type is a good example case). I think your point here is (and if I interpreted incorrectly, I'll make = a new point then), that if the encapsulated packet is L3 or L2 and = described with a port number versus a bit in the payload after the UDP = header, it would be easier for firewalls to decide when to filter one = versus the other? Dino From nobody Mon Jul 28 13:12:54 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BB81A00FE for ; Mon, 28 Jul 2014 13:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 N9vhI-5BHGku for ; Mon, 28 Jul 2014 13:12:52 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A563F1B2909 for ; Mon, 28 Jul 2014 13:12:23 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so4253873igb.3 for ; Mon, 28 Jul 2014 13:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=J6ZjgcvrigaY6fTIDrGFAcdopI0o/28o8vhj3aiV+Mo=; b=CUKJk7W5YHjagCyjVFz3lfPOmQC6yPJqrHPFhUrFXWxzac0Or+jb10Ndy396xcSvb4 vZFuFu/FxvHEVExUfPQXF7e2LZkEPJSe6BH8tgAzFh00uVfoGkhA8Cal7xxjf5B+b8TN Sh4bsgKtr2jrnHSjD6MWEMlp0kaTPvPas8OAjaFCnP/lg1n/6G45kQZOuK/BdwBEIE4v WDFvk0qUrtODgI6kAqEf9vEwNVQI/rjQTbKo9wZwRiYXteXKA9hR6r2I1JZh87w9nA5t NTJvHJy+oV6r2aUExkbLEfuYuxR0n4mHAcCG2cROwKmbdveOfV4k8noTgGKdsoj+tZf/ KvlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J6ZjgcvrigaY6fTIDrGFAcdopI0o/28o8vhj3aiV+Mo=; b=PiAhjPROGVt7D78WF6X8dvWvpnTukscTA2zUWm/6kxUmehsC59zqg4GdtmsKU/y5wR OP6M0UYK2XUygN70FtbyZakpo6WcirrBKn0FII9hhXp/lR81RYApycVT2cWPOABKcIXN MB3/RmDXUXzxFNEtcyimQh9HcKCVLsZUU9WqE5IP7n0IP6/Rtimokxh7o1PrzNSJZp+1 az2GpaV5UfnmMS+yjkkhbo0ktCJUH81CXLolAZxEc9fEecCI4A1fN4E606uZVx1l1Bl4 aoFuZnZryz4DM9HXQjpQOTMOHVvNb/utwbutaUS7JOO8e6NevtmkEEQgiKKpF8Pmn1x6 29lg== X-Gm-Message-State: ALoCoQmcW6BNjw3ARCSZCDUi2LzAMC7MjgNa6CUoRbvzbuAJehTyQkodZCm3i2DnvcDkLchldS3I MIME-Version: 1.0 X-Received: by 10.42.82.148 with SMTP id d20mr15131479icl.39.1406578342973; Mon, 28 Jul 2014 13:12:22 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Mon, 28 Jul 2014 13:12:22 -0700 (PDT) In-Reply-To: <98564227-C22C-4AB4-BB71-5E2FE76C10E4@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <53D691EB.8000402@cisco.com> <98564227-C22C-4AB4-BB71-5E2FE76C10E4@gmail.com> Date: Mon, 28 Jul 2014 13:12:22 -0700 Message-ID: From: Tom Herbert To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/8xbVWOvUq6BVMUk1SaJIVT6ZbyI Cc: Fabio Maino , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:12:53 -0000 On Mon, Jul 28, 2014 at 12:12 PM, Dino Farinacci wrot= e: > >> The caveat to this is that intermediate devices may also need to parse >> packets but not necessarily participate in the protocol control plane. >> Consider a stateless firewall that parses LISP packets to filter on >> encapsulated IP destination address. If the P-bit is implemented in >> the end hosts, but we've neglected to update all the firewalls in the >> path-- the packet will be misinterpreted if say the firewall sees a >> LISP packet with an encapsulated Ethernet frame. In this case, >> hopefully the firewall will drop the packet, but there's no guarantee >> of that-- the behavior is non-deterministic. Maintaining compatibility >> with such devices is a hard problem and might imply constraints on new >> options that could fundamental change parsing or interpretation of the >> packet (adding protocol type is a good example case). > > I think your point here is (and if I interpreted incorrectly, I'll make a= new point then), that if the encapsulated packet is L3 or L2 and described= with a port number versus a bit in the payload after the UDP header, it wo= uld be easier for firewalls to decide when to filter one versus the other? > My primary concern is not how easy it will be for firewalls to add new filtering, but rather we can make changes to protocols to ensure backwards compatibility and robustness. It is much better in the DC for devices to drop packets for things don't understand rather than to risk misinterpreting them which leads some non-deterministic behavior. Generally, I'd say that we'd want an encapsulation protocol that contains next protocol type field which is always valid as an invariant-- no P-bit indicating validity of the protocol field and no need to assign a UDP port for each protocol we might want to encapsulate (this doesn't scale and we've already gotten push-back against this model). Processing the protocol type field adds little overhead especially if we can get that down to 8-bits. GRE/UDP proposal is a good example of how this model might work, for cost of one UDP port and four bytes of packet overhead we'll be able to encapsulate any Ether_type over UDP. Adding support for this in firewalls for this should be straightforward. If the choices to extend an existing protocol are between adding P-bit and assigning a UDP port per each protocol, I still think the P-bit would be better since it is the more generic solution, but is going to be more work to ensure backwards compatibility if flags can be ignored on RX. Tom > Dino > From nobody Mon Jul 28 14:24:38 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC931A02E1 for ; Mon, 28 Jul 2014 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 wdnpRVfkLe4k for ; Mon, 28 Jul 2014 14:24:25 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE88B1A02D0 for ; Mon, 28 Jul 2014 14:24:25 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so11076053pab.6 for ; Mon, 28 Jul 2014 14:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wXhAmPSjkxaFySrCzjUi2eU0+aKJfb2omRDnjwuczkY=; b=W7Plel8Fz+76NlzwB2ENKVShvD3lxaSufXvU2OebtUGt6O6uqeeDYTlA/mulRgahH+ K98ckP0MaHBikStg5CxFRDlm1J484uNQrEUzx18FaSEjllLgDRGHvtAej+SIrK38EVd+ QFGhdOiLbEeZM7E8hOuhS6BgZIa03amEb7eIQuSvpinFdqHrLBBm1z0ccHBWy/JBmiIp /TN8HKDoJFCwxgkJ2ENTE3uhQQheO63wY6fhr45dqWibnKSZiFaY4G4/5LyLFC447IId pX8Um99CbF4cGmgd9lMJbzFYIPpBkVDexpmA7xbylylS6hJ8jlmPcLXeWdeEy1e+W1QV fF9w== X-Received: by 10.70.9.195 with SMTP id c3mr37138952pdb.21.1406582665400; Mon, 28 Jul 2014 14:24:25 -0700 (PDT) Received: from [192.168.1.79] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id av2sm18655041pbc.16.2014.07.28.14.24.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 14:24:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Mon, 28 Jul 2014 14:24:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <53D691EB.8000402@cisco.com> <98564227-C22C-4AB4-BB71-5E2FE76C10E4@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/Ccjfw-xhoOEa6i4JWTc4JGScu-Q Cc: Fabio Maino , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:24:36 -0000 > If the choices to extend an existing protocol are between adding P-bit > and assigning a UDP port per each protocol, I still think the P-bit > would be better since it is the more generic solution, but is going to > be more work to ensure backwards compatibility if flags can be ignored > on RX. But we are not starting over from scratch. There are implementations = that have been around for years. We don't have to luxury you say. And as = I said before, every time you add a feature you will need to change the = implementation anyways and deal with compatibility. So making a header = general with tons of TLV options isn't necessarily the right approach = FOR A DATA-PLANE. Versus just changing the header for the new = requirements you see in front of you at the time you design the header. And I mentioned this before at a previous NVO3 meeting. In ~30 years = since the IP header was defined, how much have we, in practice, used IP = options. Dino From nobody Mon Jul 28 14:52:39 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C425D1A028E for ; Mon, 28 Jul 2014 14:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 g1vKFnwwMgsC for ; Mon, 28 Jul 2014 14:52:29 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5CA1A024F for ; Mon, 28 Jul 2014 14:52:29 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so7176950ieb.7 for ; Mon, 28 Jul 2014 14:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nGLy/NQFrRM4uXh6SaPumLdR0PpdKZTPW61yKtsJbsA=; b=BPrQEyqXhJiAR2lpiQ7fmKaIPP5/2BvDA5ltA5CrrPgtQP0Iq/nBNOhpQmt2M7vua/ 3sCTUGd1+qgAyTrGs2/Seb6AePGQ190xsxXrMTxsOuo4EqIoBg2/hJppGYBGAYj18n0z cFzdL0MJrqdDY8C9XikZJcs/rzdNiCjwNZFAb2hXh0nbOmxzCbH320SRbPkKfeh/YQWk hCx5yeoiZfclgmV2DDaGX5eytpraDCsuPALCUuHublmhxeGZ79vnScvqqCbJfwowLJw+ KqCD4oRLhola1WjTP6oLJ7HnHt2xkopR5oyTQoyOqyeKW3DqqJGFjNVfdckzvdqtaR7Z qlHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nGLy/NQFrRM4uXh6SaPumLdR0PpdKZTPW61yKtsJbsA=; b=SvNU4GP9FAK7rKoXQdTZgaD74g0TkWgOWh4p9sN/Om2IMtX9H2ATm6w04z6OiHh+4J 7m+tVhw7WrS0ce+/zU5XC5+CV0wzd7BA8lP6egLOUFxliksN4NKZlvFBPHBu6JSpBnQv NNWLnVH2z5XGSICTFLpjJlGTqOUmS3YVi06uTDTRWK3E5XlAO72JBg7NXXetf57eVY7P fzjm9HjCbPCZm8dI2syqo72Ey+DIkV2NFWbIMnCz5BGFJoz91m+MOfihHjG0XhixDqV/ 7WTRr9XeY8cvClG38eT6PJxIhcjGklrbDIDra1E0zXRtv8FfNCIVzgVjyqLwsYT8ZB6e AlZA== X-Gm-Message-State: ALoCoQlXdb2V5tjvrdXLCNQGcoqukbmR8qFnBjyFC6WPqjxp2XBHABf9dXZ1+XCc+laObDb6cc9l MIME-Version: 1.0 X-Received: by 10.50.57.68 with SMTP id g4mr37022498igq.48.1406584348691; Mon, 28 Jul 2014 14:52:28 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Mon, 28 Jul 2014 14:52:28 -0700 (PDT) In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <53D691EB.8000402@cisco.com> <98564227-C22C-4AB4-BB71-5E2FE76C10E4@gmail.com> Date: Mon, 28 Jul 2014 14:52:28 -0700 Message-ID: From: Tom Herbert To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/aSVXUp0BorvfGIY9CpNtIE2cXrg Cc: Fabio Maino , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:52:35 -0000 On Mon, Jul 28, 2014 at 2:24 PM, Dino Farinacci wrote= : > >> If the choices to extend an existing protocol are between adding P-bit >> and assigning a UDP port per each protocol, I still think the P-bit >> would be better since it is the more generic solution, but is going to >> be more work to ensure backwards compatibility if flags can be ignored >> on RX. > > But we are not starting over from scratch. There are implementations that= have been around for years. We don't have to luxury you say. And as I said= before, every time you add a feature you will need to change the implement= ation anyways and deal with compatibility. So making a header general with = tons of TLV options isn't necessarily the right approach FOR A DATA-PLANE. = Versus just changing the header for the new requirements you see in front o= f you at the time you design the header. > I agree, at this level we don't need tons of TLV options, but we do require some basic protocol extensibility-- so to me at least GRE model is reasonable. As I have said several times now, for network virtualization we absolutely must have some mechanism to validate/authenticate the vnid at the receiver. I think the L2TP cookie is a good starting point at least, and I know that I can do this simply by appending a 64 bit field in the header like described in GUE or maybe defining a TLV in geneve-- still not sure how this could work with VXLAN. > And I mentioned this before at a previous NVO3 meeting. In ~30 years sinc= e the IP header was defined, how much have we, in practice, used IP options= . > But, how many TCP options have been defined? The reason that we don't define new IP options is because nearly all routers assume zero options for fast path, and so we can never get reasonable forwarding performance with new options. Fortunately, we've been able to extend TCP to get what we need for the most part, but we have had to make concessions because this IP options have been effectively obsoleted (I imagine something like ECN might have been done differently if IP options were a realistic option). Thanks, Tom > Dino > From nobody Mon Jul 28 15:02:12 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2767C1A00D7 for ; Mon, 28 Jul 2014 15:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 8mIypr6Tsmme for ; Mon, 28 Jul 2014 15:02:05 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D611A0080 for ; Mon, 28 Jul 2014 15:02:05 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so10458423pdj.8 for ; Mon, 28 Jul 2014 15:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Uviq1W6tcx6HF/4pjygX2+9ghElOrCFePd6Ja0Vwnv4=; b=qR1FBuUMf59VCz42k0ux6h7ur808exctW+iZVTT6CqKbf3TOIYw+logEjdpsx3VsvV h7dbtF++oTICUrVnFHkf48DU0PSHanL+Ely8FRAl1+6uUDwdBtF015OsQXR7gZLNWvTb 8IgxkjEJSCHf/Kx4dnlN3zq0TRgeez+idK2+DC7/qAkGrVHkBKRvIyslnk2YULT+s6ep cv1/kgUjKgFTMUPJXEuTFb48mC3h41bMWLmsdi/YuxuI4hAU592i2ch1T6bcQUf4RcIl fjQRXmz3aRhgTrVQ8u87u4fEwxEIcpOWNRXfqlMYvFbjcf5f9Jn59RS+Mh3K5J0QaOpc tC5g== X-Received: by 10.66.169.136 with SMTP id ae8mr41610772pac.14.1406584924457; Mon, 28 Jul 2014 15:02:04 -0700 (PDT) Received: from [192.168.1.79] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id t3sm19007513pdf.54.2014.07.28.15.02.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 15:02:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Mon, 28 Jul 2014 15:02:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <53D691EB.8000402@cisco.com> <98564227-C22C-4AB4-BB71-5E2FE76C10E4@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/sjWRuE-ShL5MxLZQCsmud-KcpdA Cc: Fabio Maino , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 22:02:09 -0000 > I agree, at this level we don't need tons of TLV options, but we do > require some basic protocol extensibility-- so to me at least GRE > model is reasonable. As I have said several times now, for network > virtualization we absolutely must have some mechanism to > validate/authenticate the vnid at the receiver. I think the L2TP > cookie is a good starting point at least, and I know that I can do That is why we created the nonce in LISP. It is already there, we don't = need an extensible header for it. I was told by many service providers = that a changing 24-bit value would be sufficient. > this simply by appending a 64 bit field in the header like described > in GUE or maybe defining a TLV in geneve-- still not sure how this > could work with VXLAN. It can't as defined other than it sets the N-bit in the header (from = LISP) and uses the nonce field. But again, we are getting design feature = merge conflicts and it is being used as a protocol demux. And allocating a port per protocol is not as bad as you think. There = won't be that many of them. At leaset we have to discpline ourselves to = not create so many (unlike what is going on right now). >> And I mentioned this before at a previous NVO3 meeting. In ~30 years = since the IP header was defined, how much have we, in practice, used IP = options. >>=20 > But, how many TCP options have been defined? The reason that we don't Software dude. > define new IP options is because nearly all routers assume zero Hardware dude. > options for fast path, and so we can never get reasonable forwarding Right, and why do they do that? The more things you put in the more = slower and costly hardware gets. Did you hear Puneet's comment at the mic last week. He is from Broadcom, = he has the battle scars on his back. He has tons of experience with = this. We NEED TO LISTEN TO HIM!!! > performance with new options. Fortunately, we've been able to extend > TCP to get what we need for the most part, but we have had to make > concessions because this IP options have been effectively obsoleted (I > imagine something like ECN might have been done differently if IP > options were a realistic option). Dino From nobody Mon Jul 28 17:38:32 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CAF1A046A for ; Mon, 28 Jul 2014 17:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Ep6kqlrU3nAR for ; Mon, 28 Jul 2014 17:38:28 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FE01A03DB for ; Mon, 28 Jul 2014 17:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=452; q=dns/txt; s=iport; t=1406594309; x=1407803909; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rgVgTJdHOFlahaFmJQUr4il8IUQyd4hVRHVeE/2HxKI=; b=m5evmvHzsnKP/H8tLREk0x9bOVqV0kkWrGgCO4P5c/tkrsbQ3AmskkyL h0MiWywbhI0EIcbjQLrSZ1OFilogpey/B5vOgXoYQ6Q8zoYy3DA4upibD L8w5tK4qvby2odxB2S4oL+E3OgJDC0J1k7K1nmq1/hcaVQbgUvqQNCQl5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAAXs1lOtJV2d/2dsb2JhbABZgw5SVwTMDYdLAYEVFneEBAEBAwE6PxACAQgOKBAyJQIEDgUbiB8IDb5aF49MB4MvgRsBBIRzApZXgVKSeoNJbIFF X-IronPort-AV: E=Sophos;i="5.01,752,1400025600"; d="scan'208";a="340376905" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2014 00:38:28 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6T0cSVu028695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 00:38:28 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 19:38:27 -0500 From: "Darrel Lewis (darlewis)" To: Tom Herbert Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqsVpFDuESdVPfU+MWLGrMK03OQ== Date: Tue, 29 Jul 2014 00:38:27 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <53D691EB.8000402@cisco.com> <98564227-C22C-4AB4-BB71-5E2FE76C10E4@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.160] Content-Type: text/plain; charset="us-ascii" Content-ID: <8AB22D0F50C2D64F987A39C90698172D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/U1BT3aWFKLXS0ixqw46swuquyJ4 Cc: "Fabio Maino \(fmaino\)" , "Darrel Lewis \(darlewis\)" , "nvo3@ietf.org" , Dino Farinacci Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 00:38:30 -0000 On Jul 28, 2014, at 1:12 PM, Tom Herbert wrote: >=20 > If the choices to extend an existing protocol are between adding P-bit > and assigning a UDP port per each protocol, I still think the P-bit > would be better since it is the more generic solution, but is going to > be more work to ensure backwards compatibility if flags can be ignored > on RX. I think this statement summarizes the trade-offs. =20 -Darrel From nobody Mon Jul 28 20:23:14 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26E1A0242; Mon, 28 Jul 2014 20:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 iUD8yANqyNtb; Mon, 28 Jul 2014 20:23:10 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD071A0005; Mon, 28 Jul 2014 20:23:09 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4C0E72AA0F; Tue, 29 Jul 2014 03:23:05 +0000 (GMT) Date: Mon, 28 Jul 2014 20:23:08 -0700 From: Marc Binderberger To: Tom Herbert Message-ID: <20140728202308389912.8bba09a4@sniff.de> In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/uUsFLm2blWqkys0CuezSiJOUYWI Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Dino Farinacci Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 03:23:12 -0000 SGVsbG8gVG9tLA0KDQpteSBwb2ludCBpcyB5b3VyICJsaW1pdHMgdGhlIHVzZWZ1bG5lc3Mi LiBUaGVyZSBpcyBzb21lIG5lZ2F0aXZlIHZpYmUgYW5kIEkgDQpkbyBub3QgYWdyZWUgd2l0 aCB0aGF0IDotKQ0KDQpBcyBtZW50aW9uZWQsIEkgYWdyZWUgd2l0aCB0aGUgc3RhdGVtZW50 IHRoYXQgaWdub3JlLW9uLXJlY2VpdmUgZmxhZ3MgbWVhbiANCnlvdSBjYW4gYWRkIG5ldyBm dW5jdGlvbmFsaXR5IG9uIHRvcCBvZiBleGlzdGluZyBvbmVzIGJ1dCBub3QgZnVuZGFtZW50 YWxseSANCmNoYW5nZSB0aGluZ3MuIEZyb20gcHJhY3RpY2FsIGV4cGVyaWVuY2Ugd2l0aCBM SVNQIGNvbnRyb2wgcGxhbmUgLSB3aGljaCBoYXMgDQppZ25vcmUtb24tcmVjZWl2ZSByZXNl cnZlZCBmaWVsZHMgLSB0aGlzIHdvcmtzIHF1aXRlIHdlbGwgYXMgaXQgYWxsb3dzIHRvIA0K YWRkLW9uIGZlYXR1cmVzIHdpdGhvdXQgYnJlYWtpbmcgdGhlIGZ1bmRhbWVudGFsIGludGVy b3Agd2l0aCBvbGRlciANCmltcGxlbWVudGF0aW9uczsgeW91IGhhdmUgdG8gZG8gaXQgInJp Z2h0IiB0byBlbnN1cmUgYSBzeXN0ZW0gbm90IA0KdW5kZXJzdGFuZGluZyB0aGUgbmV3IGZl YXR1cmUgYmVoYXZlcyBzYWZlIG9yIGF0IGxlYXN0IHJlYXNvbmFibGUgYnV0IGl0J3MgDQpk by1hYmxlLiBUaHVzIG15IHJlZmVyZW5jZSB0byBMSVNQLCBzb3JyeSB0aGlzIHdhcyBwcm9i YWJseSBjb25mdXNpbmcuDQoNCkZvciB5b3VyIExJU1AtZ3BlIGNvbW1lbnQgRmFiaW8gYW5z d2VyZWQgYWxyZWFkeSBob3cgaXQgY291bGQgd29yay4NCg0KR2VuZXJhbGx5IHNwZWFraW5n IGFib3V0IGZsYWdzLCBoYXZpbmcgYm90aCwgaWdub3JlLXdoZW4tdW5rbm93biBmbGFncyBh bmQgDQpkcm9wLXdoZW4tdW5rbm93biBmbGFncyB3b3VsZCBiZSBuaWNlIElNSE8uIFByb2Js ZW0gaXMgb3VyIGxpbWl0ZWQgc3BhY2Ugb2YgDQo2NGJpdCBzaGltIGhlYWRlciB0aG91Z2gu DQoNCg0KUmVnYXJkcywgTWFyYw0KDQoNCg0KDQpPbiBNb24sIDI4IEp1bCAyMDE0IDA4OjA4 OjMxIC0wNzAwLCBUb20gSGVyYmVydCB3cm90ZToNCj4+PiBBbGxvd2luZyB0aGUgcmVzZXJ2 ZWQgYml0cyBpbiB0aGUgaGVhZGVyIHRvIGJlIGlnbm9yZWQgb24gcmVjZWl2ZQ0KPj4+IGxp bWl0cyB0aGUgdXNlZnVsbmVzcyBpbiB0aGF0IG5ldyBiaXRzIHRoYXQgYXJlIGRlZmluZWQg Y2FuIG9ubHkgYmUNCj4+PiBhZHZpc29yeSBhbmQgbm90IGZ1bmRhbWVudGFsbHkgY2hhbmdl IGludGVycHJldGF0aW9uIG9mIHRoZSBwYWNrZXQuDQo+PiANCj4+IEkgYWdyZWUgd2l0aCB5 b3VyIHN0YXRlbWVudCBpbiB0aGUgMm5kIGhhbGYgYnV0IG5vdCB5b3VyIG9waW5pb24gYWJv dXQgdGhlDQo+PiB1c2VmdWxuZXNzLiBEb24ndCBzZWUgYSBwcm9ibGVtIGhlcmUsIExJU1Ag aXMgYSBnb29kIGV4YW1wbGUgaG93IGlnbm9yaW5nDQo+PiB1bmtub3duIGZsYWdzIHdvcmtz IHdlbGwuDQo+PiANCj4gSG93IHNvPyBBZGRpbmcgcHJvdG9jb2wgZmllbGQgdG8gTElTUC1n cGUgaGFzIHRoZSBzYW1lIGJhY2t3YXJkcw0KPiBjb21wYXRpYmlsaXR5IHByb2JsZW0gYXMg VlhMQU4tZ3BlLCBidXQgaXMgcmVzb2x2aW5nIGl0IGluIGEgZGlmZmVyZW50DQo+IHdheS4g VGhlIGFkZGl0aW9uIG9mIHRoZSBQLWJpdCByZWxpZXMgb24gc29tZSAocHJlc3VtYWJseSkg b3V0IG9mIGJhbmQNCj4gbWVjaGFuaXNtIHRvIGVuc3VyZSBwcm90b2NvbCBjb21wYXRpYmls aXR5LiBGcm9tIHRoZSBMSVNQLWdwZSBkcmFmdDoNCj4gDQo+ICJBIExJU1AtZ3BlIHJvdXRl ciBNVVNUIG5vdCBlbmNhcHN1bGF0ZSBub24tSVAgcGFja2V0cyB0byBhIExJU1ANCj4gcm91 dGVyLiAgQSBtZXRob2QgZm9yIGRldGVybWluaW5nIHRoZSBjYXBhYmlsaXRpZXMgb2YgYSBM SVNQIHJvdXRlcg0KPiAoZ3BlIG9yICJsZWdhY3kiKSBpcyBvdXQgb2YgdGhlIHNjb3BlIG9m IHRoaXMgZHJhZnQuIg0KPiANCj4gVGhhbmtzLA0KPiBUb20NCj4gDQo+PiANCj4+IFJlZ2Fy ZHMsIE1hcmMNCj4+IA0KPj4gDQo+PiANCj4+IE9uIFN1biwgMjcgSnVsIDIwMTQgMTc6Mjg6 MDEgLTA3MDAsIFRvbSBIZXJiZXJ0IHdyb3RlOg0KPj4+IE9uIFN1biwgSnVsIDI3LCAyMDE0 IGF0IDI6MjEgUE0sIERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPiANCj4+ PiB3cm90ZToNCj4+Pj4+IDIuIFRoZSBWWExBTi1HUEUgZHJhZnQgc2hvdWxkIGZvY3VzIG9u bHkgb24gdGhlIFZYTEFOLUdQRSBoZWFkZXIgYW5kDQo+Pj4+PiByZXF1aXJlcyB0aGUgYXNz aWdubWVudCBvZiBhIG5ldyBVRFAgcG9ydC4gICBUaGUgZmFjdCB0aGF0IHRoZSBWWExBTi1H UEUNCj4+Pj4+IGhlYWRlciBjbG9zZWx5IHJlc2VtYmxlcyBWWExBTiBtYXkgYmUgY29udmVu aWVudCBmb3IgaW1wbGVtZW50ZXJzLCBidXQNCj4+Pj4+IHRoaXMgcHJvdG9jb2wgYnkgZGVm aW5pdGlvbiBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIFZYTEFOLg0KPj4+PiAN Cj4+Pj4gSWYgeW91IGRvIHRoYXQgdGhlbiBpdCB3aWxsIGJlIGhhcmRlciBmb3IgVlhMQU4t R1BFIHN5c3RlbXMgdG8NCj4+Pj4gaW50ZXJvcGVyYXRlIHdpdGggYSBWWExBTiBzeXN0ZW1z LiBCZWNhdXNlIGEgVlhMQU4tR1BFIHN5c3RlbSB3aWxsIG5lZWQgDQo+Pj4+IHRvDQo+Pj4+ IG9wZW4gYW5kIG1haW50YWluIDIgVURQIHNvY2tldHMuIEFuZCBhbiBpbXBsZW1lbnRhaXRv biB3aWxsIGhhdmUgdG8gYmUNCj4+Pj4gY2FyZWZ1bCB0byBub3Qgc2V0IHRoZSBQLWJpdCBm b3IgdGhlIFZYTEFOIHNvY2tldCBvciBjbGVhciB0aGUgUC1iaXQgZm9yDQo+Pj4+IFZYTEFO LUdQRSBzb2NrZXQuIFRoaXMgaXMgYWxsIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnkgYW5kIG9u ZSB3YXkgb3IgdGhlDQo+Pj4+IG90aGVyIHNob3VsZCBiZSB1c2VkLg0KPj4+PiANCj4+PiBJ IGFtIG5vdCBzdXJlIHdoYXQgeW91IGFyZSBzdWdnZXN0aW5nLiBBRkFJQ1QgdGhlcmUgaXMg bm8gYmFja3dhcmRzDQo+Pj4gY29tcGF0aWJsZSBtZWFucyB0byB0byBhZGQgdGhlIHByb3Rv Y29sIGZpZWxkIHRvIFZYTEFOIHdoaWNoIGlzIHRoZQ0KPj4+IG1vdGl2YXRpb24gZm9yIHRo ZSBuZXcgVURQIHBvcnQsIHdoaWNoIGluIHR1cm4gaW1wbGllcyBhIG5ldyBwcm90b2NvbA0K Pj4+ICh3aGljaCBhbHNvIGltcGxpZXMgYW4gb3Bwb3J0dW5pdHkgdG8gYWRkIGEgbW9yZSBn ZW5lcmFsIHNldCBvZg0KPj4+IHByb3RvY29sIGZlYXR1cmVzIGxpa2UgdmVyc2lvbiBudW1i ZXIgYW5kIG9wdGlvbnMgZXh0ZW5zaW9ucyB3aGljaCBhcmUNCj4+PiBhbHNvIG5vdCBiYWNr d2FyZHMgY29tcGF0aWJsZSkuIE1heWJlIGl0J3MgcG9zc2libGUgdG8gYnJlYWsNCj4+PiBj b21wYXRpYmlsaXR5IHdpdGhpbiB0aGUgcHJvdG9jb2wgYW5kIGFzc3VtZSB0aGF0IG91dCBv ZiBiYW5kDQo+Pj4gbWVjaGFuaXNtcyBjb3VsZCBuZWdvdGlhdGUgdXNlIG9mIFAtYml0IHRv IGNvbXBlbnNhdGUsIGJ1dCBJIGFzc3VtZQ0KPj4+IHRoZXJlJ3MgYWxyZWFkeSBxdWl0ZSBh IGJpdCBvZiBWWExBTiBkZXBsb3ltZW50IHNvIHRoYXQgc2VlbXMgcHJldHR5DQo+Pj4gc2hh a3kgcm9idXN0bmVzcy13aXNlIHRvIG1lLg0KPj4+IA0KPj4+IEl0J3Mgbm90IGp1c3QgYWRk aW5nIHRoZSBwcm90b2NvbCBmaWVsZCB0aGF0IHdvdWxkIGJlIGFuIGlzc3VlLCBldmVuDQo+ Pj4gYWRkaW5nIHRoZSBPQU0gYml0IHRvIFZYTEFOIHdvdWxkIGJlIHByb2JsZW1hdGljLiBQ ZXIgVlhMQU4gc3BlYw0KPj4+IHVuc3BlY2lmaWVkIGZsYWcgYml0cyBhcmUgaWdub3JlZCBv biByZWNlaXZlLCBzbyBpZiB0aGUgT0FNIGJpdCB3ZXJlDQo+Pj4gc3Vic2VxdWVudGx5IGRl ZmluZWQgaW4gVlhMQU4gaXQgd2lsbCBiZSBpZ25vcmVkIGJ5IGV4aXN0aW5nDQo+Pj4gaW1w bGVtZW50YXRpb25zIGFuZCB0aGVzZSBwYWNrZXRzIHdpbGwgYmUgcHJvY2Vzc2VkIG5vcm1h bGx5LS0gdGhpcw0KPj4+IHNlZW1zIHRvIGJlIGluY29tcGF0aWJsZSB3aXRoIHRoZSBwcm9w b3NlZCBWWExBTi1ncGUgcmVxdWlyZW1lbnQgdGhhdA0KPj4+ICJXaGVuIHRoZSBPIGJpdCBp cyBzZXQgdG8gMSwgdGhlIHBhY2tldCBpcyBhbiBPQU0gcGFja2V0IGFuZCBPQU0NCj4+PiBw cm9jZXNzaW5nIE1VU1Qgb2NjdXIuIiAoYnR3ICdPQU0gcHJvY2Vzc2luZycgaXMgYXdmdWxs eSBhbWJpZ3VvdXMgdG8NCj4+PiBiZSBhIE1VU1QgaGVyZSBJTU8pLg0KPj4+IA0KPj4+IEFs bG93aW5nIHRoZSByZXNlcnZlZCBiaXRzIGluIHRoZSBoZWFkZXIgdG8gYmUgaWdub3JlZCBv biByZWNlaXZlDQo+Pj4gbGltaXRzIHRoZSB1c2VmdWxuZXNzIGluIHRoYXQgbmV3IGJpdHMg dGhhdCBhcmUgZGVmaW5lZCBjYW4gb25seSBiZQ0KPj4+IGFkdmlzb3J5IGFuZCBub3QgZnVu ZGFtZW50YWxseSBjaGFuZ2UgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHBhY2tldC4NCj4+PiBI YWQgdGhlIHJlcXVpcmVtZW50IGluIFZYTEFOIGJlZW4gdGhhdCBwYWNrZXRzIHdpdGggdW5r bm93biBiaXRzIHNldA0KPj4+IGJlIGRyb3BwZWQsIHRoZW4gYWRkaW5nIFAtYml0IGFuZCBP LWJpdCBjb3VsZCBoYXZlIGJlZW4gZG9uZSB3aXRoDQo+Pj4gYmFja3dhcmRzIGNvbXBhdGli aWxpdHkuIFRoaXMgbWlnaHQgYmUgYSByZWFzb25hYmxlIHJlcXVpcmVtZW50IHRvDQo+Pj4g Y29uc2lkZXIgaWYgbmV3IHByb3RvY29sIChpLmUuIG5ldyBwb3J0IG51bWJlcikgaXMgdW5k ZXJ0YWtlbi4NCj4+PiANCj4+PiBUaGFua3MsDQo+Pj4gVG9tDQo+Pj4gDQo+Pj4+IEFuZCBp ZiAqaXQgd2FzIGFncmVlZCogb24gdG8gdXNlIGRpZmZlcmVudCBVRFAgcG9ydCBudW1iZXJz IChsaWtlIHRoZSB3YXkNCj4+Pj4gTElTUCBkaWQgaXQgZm9yIEwyIHZlcnN1cyBMMyBwYWNr ZXQgZW5jYXBzdWxhdGlvbiksIHdlIHdvdWxkbid0IG5lZWQgdGhlDQo+Pj4+IFAtYml0IGF0 IGFsbC4gQnV0IHRoZXJlIHdhcyBwdXNoIGJhY2sgKGJ5IHNvbWVib2R5KSB0byBub3QgYWxs b2NhdGUNCj4+Pj4gYW5vdGhlciBwb3J0IGZvciBWWExBTiwgc28gdGhlIGRlbXV4IHdhcyBm b3JjZWQgdG8gYmUgaW4gdGhlIFZYTEFOIA0KPj4+PiBoZWFkZXIuDQo+Pj4+IA0KPj4+PiBB bmQgaXMgYWxzbyB0aGUgcmVhc29uIHRoaXMgYmFnZ2FnZSBpcyBiZWluZyBjYXJyaWVkIG92 ZXIgdGhlIExJU1Agd2hlbiANCj4+Pj4gaXQNCj4+Pj4gcmVhbGx5IGlzbid0IG5lZWRlZC4N Cj4+Pj4gDQo+Pj4+PiAzLiBUcnVlLCB0aGUgoVCiIGJpdCBpcyBub3QgbmVlZGVkIGZvciBi YWNrd2FyZCBjb21wYXRpYmlsaXR5LCBidXQgSaJtDQo+Pj4+PiBub3QgYWdhaW5zdCBpdCBp ZiB0aGVyZSBpcyB2YWx1ZSB0byBtYWtlIGl0IGNvbnNpc3RlbnQgd2l0aCB0aGUgTElTUC1H UEUNCj4+Pj4+IGhlYWRlci4NCj4+Pj4gDQo+Pj4+IFRoZXJlIGlzIG5vIGluY3JlbWVudGFs IGJlbmVmaXQgdG8gdXNlIHRoZSBQLWJpdCBmb3IgTElTUC4gV2UgaGFkIGENCj4+Pj4gc29s dXRpb24gYnV0IGJlY2F1c2Ugb2YgdGhlIHJlcXVpcmVtZW50IHRvIGhhdmUgbm8gbmV3IHBv cnQgZm9yIFZYTEFOLA0KPj4+PiBMSVNQIGlzIGFmZmVjdGVkLg0KPj4+PiANCj4+Pj4gSnVz dCBhbm90aGVyIGV4YW1wbGUgaG93IHRoZSB3b3JraW5nIGdyb3VwIGlzIHB1dHRpbmcgZWZm b3J0IGludG8gdGhpbmdzDQo+Pj4+IHRoYXQgY3JlYXRlcyBtb3JlIHdvcmsgYnV0IG5vIGJl bmVmaXQuIERvbid0IGdldCBtZSB3cm9uZywgdGhlIGNpc2NvIGd1eXMNCj4+Pj4gZGlkIHRo aXMgKHRoZSBWWExBTiBhbmQgTElTUCBzYW1lIHBvc2l0aW9uIGZvciBQLWJpdCkgZm9yIGNv bnNpc3RlbmN5LCANCj4+Pj4gYW5kDQo+Pj4+IHRoZXkgc2hvdWxkIGJlIGFwcGxhdWRlZCBm b3IgdGhhdC4gQnV0IGlmIFZYTEFOIGNvdWxkIGhhdmUgYW5vdGhlciBwb3J0DQo+Pj4+IG51 bWJlciBhc3NpZ25lZCBmb3IgIm90aGVyIHByb3RvY29scyIsIG1heWJlIHRoZSBWWExBTi1H UEUgd291bGQgbG9vayBzbw0KPj4+PiBtdWNoIGRpZmZlcmVudC4NCj4+Pj4gDQo+Pj4+IFNv bWV0aGluZyB0byB0aGluayBhYm91dCBhcyB0aGUgd29ya2luZyBncm91cCBub3cgaGFzIG5l dyBwcm9kdWN0aXZpdHkNCj4+Pj4gbWVudGFsaXR5Lg0KPj4+PiANCj4+Pj4gRGlubw0KPj4+ PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4+Pj4gbnZvM0BpZXRmLm9yZw0KPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCj4+PiANCj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG52 bzMgbWFpbGluZyBsaXN0DQo+Pj4gbnZvM0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0KPiA= From nobody Mon Jul 28 21:34:22 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895611A0029; Mon, 28 Jul 2014 21:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 1_loFIuj4P8m; Mon, 28 Jul 2014 21:34:20 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615541A0020; Mon, 28 Jul 2014 21:34:20 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so11638655pad.24 for ; Mon, 28 Jul 2014 21:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cOAIyk9u/QpolfOrtZofT0N5cNg+nfEvHiNgRQTqSq4=; b=nCBm5xKPjwYG3DOQcawG3H250IjVsmJfYQcBj99XCyz4F2BWWkRTr0+NWfQc1tK2Y2 rcTNSp9/GuMKcfR3uN9rmlvUqk5xrvgLcUp4QPftSlCp7tQCKK7Wm1K+w0WHm9enAtIa 1rVufzHJAIUTOjjBZ8DLxdSUcIRWZTRbqySSe3WOaSutS91xS5nKnW5lOVKCHGaBz520 2KjMTXzEl7T8Du/z3qAVVk7zkAwCDuS3s1B9Jf/3QyNteJ3RrAm8DcuzylhRuzoLvYWe XXYAMrLKnc/U+kxTusKlaN7BpJ/hvfHX85zTb9MQkq+Lntzxkwek96paqLxdCZ/FUAYy 3eUA== X-Received: by 10.69.17.230 with SMTP id gh6mr43357015pbd.0.1406608460038; Mon, 28 Jul 2014 21:34:20 -0700 (PDT) Received: from [192.168.1.79] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id jb5sm19331491pbd.73.2014.07.28.21.34.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 21:34:17 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <20140728202308389912.8bba09a4@sniff.de> Date: Mon, 28 Jul 2014 21:34:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/yt8XHDPqKwO6UZ7jUxpJjR9RzLA Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 04:34:21 -0000 > Generally speaking about flags, having both, ignore-when-unknown flags = and=20 > drop-when-unknown flags would be nice IMHO. Problem is our limited = space of=20 > 64bit shim header though. The flag bits in the LISP header are not used that way. They are = enable-bits so you can overload fields and keep the header small. The = flags are designed based on "enable-bits" in many hardware designs where = the enable-bits indicate which parallel signal lines are in effect = (voltage, verify, ECC, parity, etc). The bits do not mean anything about how the packet is handled but what = control data is transmitted with the data-packet. Dino From nobody Mon Jul 28 21:52:21 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AC51A004A; Mon, 28 Jul 2014 21:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 hBCAakwNI8f3; Mon, 28 Jul 2014 21:52:18 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C022A1A0026; Mon, 28 Jul 2014 21:52:17 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id DB2012AA0F; Tue, 29 Jul 2014 04:52:12 +0000 (GMT) Date: Mon, 28 Jul 2014 21:52:13 -0700 From: Marc Binderberger To: Dino Farinacci Message-ID: <20140728215213292302.e07f5538@sniff.de> In-Reply-To: <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/HDD-nVllD4SebhxERwGEkVbbh0I Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 04:52:18 -0000 Hello Dino, thanks for this comment - that's an interesting point of view. Hmm, how do the O (or RA in another draft) and the P bit fit into this picture? They do mean something about how the packet is handled, don't they? Regards, Marc On Mon, 28 Jul 2014 21:34:15 -0700, Dino Farinacci wrote: >> Generally speaking about flags, having both, ignore-when-unknown flags and >> drop-when-unknown flags would be nice IMHO. Problem is our limited space >> of >> 64bit shim header though. > > The flag bits in the LISP header are not used that way. They are > enable-bits so you can overload fields and keep the header small. The flags > are designed based on "enable-bits" in many hardware designs where the > enable-bits indicate which parallel signal lines are in effect (voltage, > verify, ECC, parity, etc). > > The bits do not mean anything about how the packet is handled but what > control data is transmitted with the data-packet. > > Dino > From nobody Mon Jul 28 22:08:53 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F61A004A; Mon, 28 Jul 2014 22:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 QcI7CMoGH8pi; Mon, 28 Jul 2014 22:08:47 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42451A007C; Mon, 28 Jul 2014 22:08:47 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id ft15so11142255pdb.3 for ; Mon, 28 Jul 2014 22:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=odzLKx4Q9xavCk8T2lfHwvwDohpyeoedkbh3sFv2utw=; b=woFQjzCSQRwlVLx2OkZyfCEjlxeX54/YTfZ4nXr+nwTuDjuBluqjCWqMZValaFhSzG 6ggqf82tOpTyMQhQ8HeaDhTAyLub5DjJjerVqT6G6Xnui++rXVCHUTpdmJaojWB9yeFJ wLRjzhd44Ni5AcUx8APVRxeN7ZWHHj68hgl6MFg/3tyd375sB/xqB/XJQcHFGu/+/Law CQpWvzV1ryv5AUFy8IWSMSoAGz4hldKVprvIeqLz4tY8jq6EQdphJM+bprdeOUamXyt7 J9MjV7XEt3gey+Bz9fOgz2lPGk4BpEUgkRmakJH+NP6KwQRhiT8/shb4hWmqemclNoNT CybA== X-Received: by 10.66.137.11 with SMTP id qe11mr43204193pab.80.1406610527287; Mon, 28 Jul 2014 22:08:47 -0700 (PDT) Received: from [192.168.1.34] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id qw8sm73692655pab.17.2014.07.28.22.08.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 22:08:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: <20140728215213292302.e07f5538@sniff.de> Date: Mon, 28 Jul 2014 22:08:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> To: Marc Binderberger Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/cKqopSYIW5-Tk6z7JCZKdP3Zeb8 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 05:08:49 -0000 > On Jul 28, 2014, at 9:52 PM, Marc Binderberger wrote: >=20 > Hello Dino, >=20 > thanks for this comment - that's an interesting point of view. >=20 > Hmm, how do the O (or RA in another draft) and the P bit fit into this=20 O-bit in LISP is not needed. I told the LUSP-GPE authors this. Because OAM-p= ackets like all other control packets go in UDP port 4342 (where encapsulate= d packets go in UDP port 4341).=20 And P-bit is not needed and the authors indicated the main motivation was to= keep consistent with VXLAN so same hardware design could do both. LISP alre= ady has port 8473 for L2 frames. And NSH is a service protocol and should ru= n above the transport layer so should have its own port and can address pack= ets anywhere. Just like any other UDP application. If that packet needs to b= e encapsulated that is a lower level function. Just like IP packets can go i= n an MPLS based LSP.=20 > picture? They do mean something about how the packet is handled, don't th= ey? I won't answer that because those bit introductions into the design are inde= ed design bugs IMO.=20 Dino= From nobody Tue Jul 29 03:58:34 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538741B27A5; Tue, 29 Jul 2014 03:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.348 X-Spam-Level: ** X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dx1slHYyZba0; Tue, 29 Jul 2014 03:58:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF3D1B27A2; Tue, 29 Jul 2014 03:58:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHR92588; Tue, 29 Jul 2014 10:58:25 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Jul 2014 11:58:24 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 18:58:18 +0800 From: Haoweiguo To: Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqm7PMm9q7yrP70OlSuBAct24iJu2p0TR Date: Tue, 29 Jul 2014 10:58:17 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> , <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> , <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> In-Reply-To: <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/r-ibPClOdQYWB1tNz2EyUETa9eM Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: [nvo3] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9uIGh0dHA6Ly90b29scy5p?= =?gb2312?b?ZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 10:58:30 -0000 SGkgRGlubywNClRoYW5rcyBmb3IgeW91ciBkZXRhaWwgY29tbWVudHMuICBBcyBmb3IgY3VycmVu dCBWWExBTiBlbmNhcHN1bGF0aW9uLCBwbHMgc2VlIG15IGNvbW1lbnRzIGlubGluZSB3aXRoIFt3 ZWlndW9dIGJlbG93Lg0KDQpUaGVyZSBpcyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBlbmNhcHN1 bGF0aW9uIGhlYWRlciAod2hpY2ggaXMgY2FsbGVkIFZYTEFOLUdQRSkgc28gaXQgY2FuIHN1cHBv cnQsIG1vc3QgaW1wb3J0YW50bHkgTlNILiBUaGF0IGNoYW5nZSBhbHNvIGdpdmVzIFZYTEFOIHRv IHN1cHBvcnQgZW5jYXBzdWxhdGluZyBsYXllci0yIElQdjQgYW5kIElQdjYsIHdoaWNoIGlzIGR1 cGxpY2F0ZSBmdW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUgc28gc2lt aWxhciwgaXQgcmVhbGx5IGRvZW5zJ3QgbWF0dGVyLg0KDQpbd2VpZ3VvXTogWWVzLCBhbiBuZXcg ZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgTlNILiBC dXQgYXMgZm9yIElQdjQgYW5kIElQdjYsIGkgdGhpbmsgY3VycmVudCBWWExBTiBhbHJlYWR5IHN1 cHBvcnRlZC4gIEZvciB0aGUgbGF5ZXIgMyBpbnRlci1zdWJuZXQgdHJhZmZpYyBmcm9tIE5WRTEg dG8gTlZFMiwgaW5uZXIgZGVzdGluYXRpb24gTUFDIGlzIHRoZSBnYXRld2F5IGludGVyZmFjZSBN QUMgYXQgTlZFMi4gIEZvciB0aGUgbGF5ZXIgMiBpbnRyYS1zdWJuZXQgdHJhZmZpYyBmcm9tIE5W RTEgdG8gTlZFMiwgIGlubmVyIGRlc3RpbmF0aW9uIE1BQyBpcyB0aGUgZGVzdGluYXRpb24gVFMn cyBNQUMuIFdoZW4gTlZFMiByZWNlaXZlcyBWWExBTiBlbmNhcHN1bGF0ZWQgdHJhZmZpYyBmcm9t IE5WRTEsIGlubmVyIGRlc3RpbmF0aW9uIE1BQyBjYW4gYmUgdXNlZCB0byBkaWZmZXJlbnRpYXRl IGxheWVyIDIgdHJhZmZpYyBmcm9tIGxheWVyIDMgdHJhZmZpYy4gVlhMQU4gZGlzdHJpYnV0ZWQg bGF5ZXIgMyBnYXRld2F5IGNhbiBiZSByZWFsaXplZCB0aHJvdWdoIHRoZSBtZWNoYW5pc20sIE5W RSBjYW4gZm9yd2FyZCBib3RoIGludHJhLXN1Ym5ldCBsYXllciAyIHRyYWZmaWMgYW5kIGludGVy LXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgYXQgdGhlIHNhbWUgdGltZS4NCg0KVGhhbmtzDQp3ZWln dW8gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IERp bm8gRmFyaW5hY2NpIFtmYXJpbmFjY2lAZ21haWwuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjI4 yNUgMjI6MTcNCsrVvP7IyzogSGFvd2VpZ3VvDQqzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0 Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQrW98ziOiBSZTogW252 bzNdIENvbW1lbnRzIG9uIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4 bGFuLWdwZS0wMw0KDQo+IEhpIERpbm8sDQo+IFNvcnJ5LCBpIG1pc3VuZGVyc3Rvb2QgeW91LiBJ IHRoaW5rIFZYTEFOLUdQRSBjYW4gZGVmaW5lIGEgbmV3IFVEUCBwb3J0IGFuZCBhIG5ldyBkYXRh IGZvcm1hdCwgUCBiaXQNCg0KTm8gd29ycmllcy4NCg0KPiBpbiBWWExBTi1HUEUgc2VlbXMgdG8g aGF2ZSBubyBhbnkgdmFsdWUuIEFzIGZvciBiYXNpYyBpbnRlci1zdWJuZXQgbGF5ZXIgMyBjb21t dW5pY2F0aW9uIGFuZCBpbnRyYS1zdWJuZXQgbGF5ZXIgMiBjb21tdW5pY2F0aW9uIGJldHdlZW4g TlZFcywgY3VycmVudCBOVkdSRSwgVlhMQU4gYW5kIExJU1AgaGF2ZSBhbHJlYWR5IHN1cHBvcnRl ZCwNCg0KVlhMQU4gc3VwcG9ydHMgTDIgb3ZlcmxheXMgc2luY2UgaXRzIGdvYWwgaXMgdG8gZXh0 ZW5kIHN1Ym5ldHMuIExJU1Agc3VwcG9ydHMgTDMgb3ZlcmxheXMgc28gaXQgYXNzdW1lcyBzdWJu ZXRzIGFyZSBsb2NhbCAodG8gdGhlIHhUUikganVzdCBsaWtlIGluIGEgcm91dGVkIG5ldHdvcmsu IE5WR1JFIGNhbiBiZSBhIGNvbWJvLg0KDQo+IE5WR1JFLFZYTEFOLExJU1AgYW5kIFZYTEFOLUdQ RSBjYW4gYmUgaHlicmlkIHVzZWQgdG8gZm9ybSBhIE5WTzMgbmV0d29yayBpZiBvbmx5IGJhc2lj IGxheWVyIDMgYW5kDQoNClRoZXJlIGlzIG1vdGl2YXRpb24gdG8gZXh0ZW5kIGFuIGVuY2Fwc3Vs YXRpb24gaGVhZGVyICh3aGljaCBpcyBjYWxsZWQgVlhMQU4tR1BFKSBzbyBpdCBjYW4gc3VwcG9y dCwgbW9zdCBpbXBvcnRhbnRseSBOU0guIFRoYXQgY2hhbmdlIGFsc28gZ2l2ZXMgVlhMQU4gdG8g c3VwcG9ydCBlbmNhcHN1bGF0aW5nIGxheWVyLTIgSVB2NCBhbmQgSVB2Niwgd2hpY2ggaXMgZHVw bGljYXRlIGZ1bmN0aW9uYWxpdHkgb2YgTElTUC4gQnV0IHRoZSBoZWFkZXJzIGFyZSBzbyBzaW1p bGFyLCBpdCByZWFsbHkgZG9lbnMndCBtYXR0ZXIuDQoNCkhvd2V2ZXIsIHRoZSBQLWJpdCBpcyBu b3QgbmVlZGVkIGZvciBhbnl0aGluZyBuZXcgaW4gTElTUCBhbmQgdGhlIE9BTS1iaXQgaXMgbm90 IG5lZWRlZCBpbiBMSVNQIHNpbmNlIExJU1AgaGFzIGRpZmZlcmVudCBVRFAgcG9ydCBudW1iZXIg KDQzNDIpIGZvciBjb250cm9sLXBhY2tldHMuIFZYTEFOIGRvZXMgbm90IGhhdmUgYSB3ZWxsIGRl ZmluZWQgY29udHJvbCBwcm90b2NvbCBzbyB0aGUgZGF0YS1wbGFuZSBoYXMgdG8gZXNjYXBlIG91 dCBjb250cm9sLXBsYW5lIHBha2NldHMgd2hlcmUgdGhlIGZpcnN0IG9uZSBpcyB0aGlzIG5ldyBP QU0gbWVzc2FnZS4NCg0KPiBsYXllciAyIGZvcndhcmRpbmcgcHJvY2VzcyBleGlzdHMuIEFzIGZv ciBzb21lIGV4dHJhIGZ1bmN0aW9ucyBvZiBPQU0sIHNlcnZpY2UgY2hhaW5pbmcsYW5kIGV0Yywg IG9ubHkgVlhMQU4tR1BFIGNhbiBzdXBwb3J0LCBwdXJlIFZYTEFOLUdQRSBuZXR3b3JrIHNob3Vs ZCBiZSB1c2VkIGluIHRoZXNlIGNhc2VzLg0KPiBUaGFua3MNCj4gd2VpZ3VvDQoNClJpZ2h0LCBh Z3JlZS4NCg0KRGlubw0KDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gt6K8/sjLOiBEaW5vIEZhcmluYWNjaSBbZmFyaW5hY2NpQGdtYWlsLmNvbV0N Cj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4yNUgMjE6MTUNCj4gytW8/sjLOiBIYW93ZWlndW8NCj4g s63LzTogVG9tIEhlcmJlcnQ7IERhdmlkIE1lbG1hbjsgbnZvM0BpZXRmLm9yZzsgTElTUCBtYWls aW5nIGxpc3QgbGlzdA0KPiDW98ziOiBSZTogtPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KPg0KPj4gT24g SnVsIDI4LCAyMDE0LCBhdCA3OjI0IEFNLCBIYW93ZWlndW8gPGhhb3dlaWd1b0BodWF3ZWkuY29t PiB3cm90ZToNCj4+DQo+PiBBYm91dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBpIGFsc28gYWdy ZWUgd2l0aCBEaW5vLiBWWExBTi1HUEUgc2hvdWxkIGZvY3VzIG9uICB0aGUgVlhMQU4tR1BFIGhl YWRlciBhbmQgcmVxdWlyZXMgdGhlIGFzc2lnbm1lbnQgb2YgYSBuZXcgVURQIHBvcnQsIHRoZSBk YXRhIGZvcm1hdCBkb24ndCBuZWVkIGNvbnNpZGVyIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0 aCBWWExBTiBoZWFkZXIuIEkNCj4NCj4gSSB3YW50IHRvIG1ha2UgaXQgY2xlYXIgdGhhdCBzdXBw b3J0aW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXMgdmVyeSBpbXBvcnRhbnQgc2luY2UgVlhM QU4tcG9ydC00Nzg5IGlzIHN1cHBvcnRlZCBpbiB2YXJpb3VzIGNoaXBzIGFscmVhZHkuDQo+DQo+ IERpbm8= From nobody Tue Jul 29 05:18:35 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786301B2819; Tue, 29 Jul 2014 05:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 0UAXTdJIIZe9; Tue, 29 Jul 2014 05:18:18 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32691B282C; Tue, 29 Jul 2014 05:18:10 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id g10so11553486pdj.15 for ; Tue, 29 Jul 2014 05:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LHRyLm087RU9i3Nka5jPJFdOMHjaFZePCBm50JQqlbA=; b=qGJbr6cfRvhUJnGYV0l/RCxKypCpJoTeHQJPzHnWdrp+sEDjsEclchYfrg+mUoQztH cX1VyMRcrCQEuDv1omH1poK3ShE/vFyLpJpzBgkdG6925OqZw0VPAVcdkMmsquoqwhe1 On7JjDP9qClDCL0E1fi/AxmYBYtgLpVf5Oa7qLkIo+PkkuCJEZJX5CfM60A+9FZFbIGz xaiMZ/7OpTMKEF7nQLluOrMv37rDKyUUCoqmfduytKNQaT0Qtjus8EvJGdIxnQWnP512 CAGp4+EO/22hAUdj5hnBUloXE3Fgt/I3qDN0LPXuwZXwjq+2uEmS2JQHTem0tTNUC/Ol Lm2A== X-Received: by 10.70.134.193 with SMTP id pm1mr1572217pdb.117.1406636290515; Tue, 29 Jul 2014 05:18:10 -0700 (PDT) Received: from [10.237.165.106] (mobile-166-137-179-195.mycingular.net. [166.137.179.195]) by mx.google.com with ESMTPSA id t3sm21851175pdf.54.2014.07.29.05.18.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 05:18:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Tue, 29 Jul 2014 05:18:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> To: Haoweiguo Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/6kB7w6W07vw1xxyGHZTE3BvvhD0 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] =?utf-8?b?562U5aSNOiAgQ29tbWVudHMgb24gaHR0cDovL3Rvb2xzLmll?= =?utf-8?q?tf=2Eorg/html/draft-quinn-vxlan-gpe-03?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 12:18:19 -0000 I understand what you are saying but it comes down to what the encapsulator i= s encapsulating. If the packet it is encapsulating is an L2 frame then the e= ncapsulator is supporting a layer-2 overlay service. Otherwise it is a a lay= er-3 overlay service.=20 If the dest MAC Is to the encapsulator that MAC header is stripped before a l= ayer-3 forwarding decision is made. Then, at which time the packet is forwar= ded natively or encapsulated. If the dest MAC is not the encapsulator's address, then the MAC header stays= with the packet/frame and then encapsulated.=20 The former is a layer-3 overlay and the latter is a layer-2 overlay where bo= th can be supported at the same time in one encapsulator device.=20 The former is LISP encapsulation and the latter is VXLAN encapsulation.=20 With VXLAN-GPE both cases can be supported (and most importantly with a sing= le unified control-plane).=20 So I believe VXLAN-GPE could be useful yet redundant but LISP requires no ch= anges (if LISP supports L2 which is documented in draft-smith-lisp-layer-2 u= sing a different port number).=20 Dino > On Jul 29, 2014, at 3:58 AM, Haoweiguo wrote: >=20 > Hi Dino, > Thanks for your detail comments. As for current VXLAN encapsulation, pls s= ee my comments inline with [weiguo] below. >=20 > There is motivation to extend an encapsulation header (which is called VXL= AN-GPE) so it can support, most importantly NSH. That change also gives VXLA= N to support encapsulating layer-2 IPv4 and IPv6, which is duplicate functio= nality of LISP. But the headers are so similar, it really doens't matter. >=20 > [weiguo]: Yes, an new encapsulation header should be extended to support N= SH. But as for IPv4 and IPv6, i think current VXLAN already supported. For t= he layer 3 inter-subnet traffic from NVE1 to NVE2, inner destination MAC is t= he gateway interface MAC at NVE2. For the layer 2 intra-subnet traffic from= NVE1 to NVE2, inner destination MAC is the destination TS's MAC. When NVE2= receives VXLAN encapsulated traffic from NVE1, inner destination MAC can be= used to differentiate layer 2 traffic from layer 3 traffic. VXLAN distribut= ed layer 3 gateway can be realized through the mechanism, NVE can forward bo= th intra-subnet layer 2 traffic and inter-subnet layer 3 traffic at the same= time. >=20 > Thanks > weiguo=20 > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8828=E6=97=A5 2= 2:17 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo > =E6=8A=84=E9=80=81: David Melman; nvo3@ietf.org; LISP mailing list list; T= om Herbert > =E4=B8=BB=E9=A2=98: Re: [nvo3] Comments on http://tools.ietf.org/html/draf= t-quinn-vxlan-gpe-03 >=20 >> Hi Dino, >> Sorry, i misunderstood you. I think VXLAN-GPE can define a new UDP port a= nd a new data format, P bit >=20 > No worries. >=20 >> in VXLAN-GPE seems to have no any value. As for basic inter-subnet layer 3= communication and intra-subnet layer 2 communication between NVEs, current N= VGRE, VXLAN and LISP have already supported, >=20 > VXLAN supports L2 overlays since its goal is to extend subnets. LISP suppo= rts L3 overlays so it assumes subnets are local (to the xTR) just like in a r= outed network. NVGRE can be a combo. >=20 >> NVGRE,VXLAN,LISP and VXLAN-GPE can be hybrid used to form a NVO3 network i= f only basic layer 3 and >=20 > There is motivation to extend an encapsulation header (which is called VXL= AN-GPE) so it can support, most importantly NSH. That change also gives VXLA= N to support encapsulating layer-2 IPv4 and IPv6, which is duplicate functio= nality of LISP. But the headers are so similar, it really doens't matter. >=20 > However, the P-bit is not needed for anything new in LISP and the OAM-bit i= s not needed in LISP since LISP has different UDP port number (4342) for con= trol-packets. VXLAN does not have a well defined control protocol so the dat= a-plane has to escape out control-plane pakcets where the first one is this n= ew OAM message. >=20 >> layer 2 forwarding process exists. As for some extra functions of OAM, se= rvice chaining,and etc, only VXLAN-GPE can support, pure VXLAN-GPE network s= hould be used in these cases. >> Thanks >> weiguo >=20 > Right, agree. >=20 > Dino >=20 >>=20 >>=20 >> ________________________________________ >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8828=E6=97=A5 2= 1:15 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo >> =E6=8A=84=E9=80=81: Tom Herbert; David Melman; nvo3@ietf.org; LISP mailin= g list list >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [nvo3] Comments on http://too= ls.ietf.org/html/draft-quinn-vxlan-gpe-03 >>=20 >>> On Jul 28, 2014, at 7:24 AM, Haoweiguo wrote: >>>=20 >>> About backward compatibility, i also agree with Dino. VXLAN-GPE should f= ocus on the VXLAN-GPE header and requires the assignment of a new UDP port,= the data format don't need consider backward compatibility with VXLAN heade= r. I >>=20 >> I want to make it clear that supporting backward compatibility is very im= portant since VXLAN-port-4789 is supported in various chips already. >>=20 >> Dino From nobody Tue Jul 29 20:15:30 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853371A0415; Tue, 29 Jul 2014 20:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hqn2iqCgLk5r; Tue, 29 Jul 2014 20:15:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE881A04B1; Tue, 29 Jul 2014 20:15:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKR36527; Wed, 30 Jul 2014 03:15:24 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Jul 2014 04:15:23 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 30 Jul 2014 11:15:20 +0800 From: Haoweiguo To: Dino Farinacci Thread-Topic: =?gb2312?B?tPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0dHA6Ly90b29scy5pZXRmLm9y?= =?gb2312?Q?g/html/draft-quinn-vxlan-gpe-03?= Thread-Index: AQHPqm7PMm9q7yrP70OlSuBAct24iJu2p0TR///MEgCAAXwojA== Date: Wed, 30 Jul 2014 03:15:19 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> , <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> In-Reply-To: <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/KDo96Slwmo2oa01PWUz9Qpz_tdU Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: [nvo3] =?gb2312?b?tPC4tDogtPC4tDogIENvbW1lbnRzIG9uIGh0dHA6Ly90?= =?gb2312?b?b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 03:15:28 -0000 SGkgRGlubywNClZYTEFOIGNhbiB1c2UgYSB1bmlmaWVkIGVuY2Fwc3VsYXRpb24gdG8gcmVhbGl6 ZSBib3RoIGludHJhLXN1Ym5ldCBsYXllciAyIHRyYWZmaWMgZm9yd2FyZGluZyBhbmQgaW50ZXIt c3VibmV0IGxheWVyIDMgdHJhZmZpYyBmb3J3YXJkaW5nIGF0IHRoZSBzYW1lIHRpbWUsIGlubmVy IGRlc3RpbmF0aW9uIE1BQyBpcyB1c2VkIHRvIGRpZmZlcmVuY2lhdGUgbGF5ZXIgMiB0cmFmZmlj IGZyb20gbGF5ZXIgMyB0cmFmZmljLiANCkxJU1AgdXNlcyB0d28gZGlmZmVyZW50IGVuY2Fwc3Vs YXRpb25zIGZvciBpbnRyYS1zdWJuZXQgbGF5ZXIgMiB0cmFmZmljIGZvcndhcmRpbmcgYW5kIGlu dGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgZm9yd2FyZGluZywgVURQIHBvcnQgaXMgdXNlZCB0 byBkaWZmZXJlbmNpYXRlIGxheWVyIDIgdHJhZmZpYyBmcm9tIGxheWVyIDMgdHJhZmZpYy4NCkZy b20gdGhlb3JldGljYWwgcGVyc3BlY3RpdmUsICBib3RoIHRoZSB0d28gc29sdXRpb25zIGFyZSBh cHBsaWNhYmxlLiBGcm9tIGNvbW1lcmNpYWwgdXNlIHBlcnNwZWN0aXZlLCB0aGUgZm9ybWVyKHVu aWZpZWQgZW5jYXAgZm9yIGJvdGggbGF5ZXIgMiBhbmQgbGF5ZXIgMykgc2VlbXMgdG8gYmUgbW9y ZSBwb3B1bGFyIGN1cnJlbnRseS4NClRoYW5rcw0Kd2VpZ3VvDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IERpbm8gRmFyaW5hY2NpIFtmYXJpbmFjY2lA Z21haWwuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjI5yNUgMjA6MTgNCsrVvP7IyzogSGFvd2Vp Z3VvDQqzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0 IGxpc3Q7IFRvbSBIZXJiZXJ0DQrW98ziOiBSZTogtPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KDQpJIHVu ZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHNheWluZyBidXQgaXQgY29tZXMgZG93biB0byB3aGF0IHRo ZSBlbmNhcHN1bGF0b3IgaXMgZW5jYXBzdWxhdGluZy4gSWYgdGhlIHBhY2tldCBpdCBpcyBlbmNh cHN1bGF0aW5nIGlzIGFuIEwyIGZyYW1lIHRoZW4gdGhlIGVuY2Fwc3VsYXRvciBpcyBzdXBwb3J0 aW5nIGEgbGF5ZXItMiBvdmVybGF5IHNlcnZpY2UuIE90aGVyd2lzZSBpdCBpcyBhIGEgbGF5ZXIt MyBvdmVybGF5IHNlcnZpY2UuDQoNCklmIHRoZSBkZXN0IE1BQyBJcyB0byB0aGUgZW5jYXBzdWxh dG9yIHRoYXQgTUFDIGhlYWRlciBpcyBzdHJpcHBlZCBiZWZvcmUgYSBsYXllci0zIGZvcndhcmRp bmcgZGVjaXNpb24gaXMgbWFkZS4gVGhlbiwgYXQgd2hpY2ggdGltZSB0aGUgcGFja2V0IGlzIGZv cndhcmRlZCBuYXRpdmVseSBvciBlbmNhcHN1bGF0ZWQuDQoNCklmIHRoZSBkZXN0IE1BQyBpcyBu b3QgdGhlIGVuY2Fwc3VsYXRvcidzIGFkZHJlc3MsIHRoZW4gdGhlIE1BQyBoZWFkZXIgc3RheXMg d2l0aCB0aGUgcGFja2V0L2ZyYW1lIGFuZCB0aGVuIGVuY2Fwc3VsYXRlZC4NCg0KVGhlIGZvcm1l ciBpcyBhIGxheWVyLTMgb3ZlcmxheSBhbmQgdGhlIGxhdHRlciBpcyBhIGxheWVyLTIgb3Zlcmxh eSB3aGVyZSBib3RoIGNhbiBiZSBzdXBwb3J0ZWQgYXQgdGhlIHNhbWUgdGltZSBpbiBvbmUgZW5j YXBzdWxhdG9yIGRldmljZS4NCg0KVGhlIGZvcm1lciBpcyBMSVNQIGVuY2Fwc3VsYXRpb24gYW5k IHRoZSBsYXR0ZXIgaXMgVlhMQU4gZW5jYXBzdWxhdGlvbi4NCg0KV2l0aCBWWExBTi1HUEUgYm90 aCBjYXNlcyBjYW4gYmUgc3VwcG9ydGVkIChhbmQgbW9zdCBpbXBvcnRhbnRseSB3aXRoIGEgc2lu Z2xlIHVuaWZpZWQgY29udHJvbC1wbGFuZSkuDQoNClNvIEkgYmVsaWV2ZSBWWExBTi1HUEUgY291 bGQgYmUgdXNlZnVsIHlldCByZWR1bmRhbnQgYnV0IExJU1AgcmVxdWlyZXMgbm8gY2hhbmdlcyAo aWYgTElTUCBzdXBwb3J0cyAgTDIgd2hpY2ggaXMgZG9jdW1lbnRlZCBpbiBkcmFmdC1zbWl0aC1s aXNwLWxheWVyLTIgdXNpbmcgYSBkaWZmZXJlbnQgcG9ydCBudW1iZXIpLg0KDQpEaW5vDQoNCj4g T24gSnVsIDI5LCAyMDE0LCBhdCAzOjU4IEFNLCBIYW93ZWlndW8gPGhhb3dlaWd1b0BodWF3ZWku Y29tPiB3cm90ZToNCj4NCj4gSGkgRGlubywNCj4gVGhhbmtzIGZvciB5b3VyIGRldGFpbCBjb21t ZW50cy4gIEFzIGZvciBjdXJyZW50IFZYTEFOIGVuY2Fwc3VsYXRpb24sIHBscyBzZWUgbXkgY29t bWVudHMgaW5saW5lIHdpdGggW3dlaWd1b10gYmVsb3cuDQo+DQo+IFRoZXJlIGlzIG1vdGl2YXRp b24gdG8gZXh0ZW5kIGFuIGVuY2Fwc3VsYXRpb24gaGVhZGVyICh3aGljaCBpcyBjYWxsZWQgVlhM QU4tR1BFKSBzbyBpdCBjYW4gc3VwcG9ydCwgbW9zdCBpbXBvcnRhbnRseSBOU0guIFRoYXQgY2hh bmdlIGFsc28gZ2l2ZXMgVlhMQU4gdG8gc3VwcG9ydCBlbmNhcHN1bGF0aW5nIGxheWVyLTIgSVB2 NCBhbmQgSVB2Niwgd2hpY2ggaXMgZHVwbGljYXRlIGZ1bmN0aW9uYWxpdHkgb2YgTElTUC4gQnV0 IHRoZSBoZWFkZXJzIGFyZSBzbyBzaW1pbGFyLCBpdCByZWFsbHkgZG9lbnMndCBtYXR0ZXIuDQo+ DQo+IFt3ZWlndW9dOiBZZXMsIGFuIG5ldyBlbmNhcHN1bGF0aW9uIGhlYWRlciBzaG91bGQgYmUg ZXh0ZW5kZWQgdG8gc3VwcG9ydCBOU0guIEJ1dCBhcyBmb3IgSVB2NCBhbmQgSVB2NiwgaSB0aGlu ayBjdXJyZW50IFZYTEFOIGFscmVhZHkgc3VwcG9ydGVkLiAgRm9yIHRoZSBsYXllciAzIGludGVy LXN1Ym5ldCB0cmFmZmljIGZyb20gTlZFMSB0byBOVkUyLCBpbm5lciBkZXN0aW5hdGlvbiBNQUMg aXMgdGhlIGdhdGV3YXkgaW50ZXJmYWNlIE1BQyBhdCBOVkUyLiAgRm9yIHRoZSBsYXllciAyIGlu dHJhLXN1Ym5ldCB0cmFmZmljIGZyb20gTlZFMSB0byBOVkUyLCAgaW5uZXIgZGVzdGluYXRpb24g TUFDIGlzIHRoZSBkZXN0aW5hdGlvbiBUUydzIE1BQy4gV2hlbiBOVkUyIHJlY2VpdmVzIFZYTEFO IGVuY2Fwc3VsYXRlZCB0cmFmZmljIGZyb20gTlZFMSwgaW5uZXIgZGVzdGluYXRpb24gTUFDIGNh biBiZSB1c2VkIHRvIGRpZmZlcmVudGlhdGUgbGF5ZXIgMiB0cmFmZmljIGZyb20gbGF5ZXIgMyB0 cmFmZmljLiBWWExBTiBkaXN0cmlidXRlZCBsYXllciAzIGdhdGV3YXkgY2FuIGJlIHJlYWxpemVk IHRocm91Z2ggdGhlIG1lY2hhbmlzbSwgTlZFIGNhbiBmb3J3YXJkIGJvdGggaW50cmEtc3VibmV0 IGxheWVyIDIgdHJhZmZpYyBhbmQgaW50ZXItc3VibmV0IGxheWVyIDMgdHJhZmZpYyBhdCB0aGUg c2FtZSB0aW1lLg0KPg0KPiBUaGFua3MNCj4gd2VpZ3VvDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBEaW5vIEZhcmluYWNjaSBbZmFyaW5hY2Np QGdtYWlsLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4yNUgMjI6MTcNCj4gytW8/sjLOiBI YW93ZWlndW8NCj4gs63LzTogRGF2aWQgTWVsbWFuOyBudm8zQGlldGYub3JnOyBMSVNQIG1haWxp bmcgbGlzdCBsaXN0OyBUb20gSGVyYmVydA0KPiDW98ziOiBSZTogW252bzNdIENvbW1lbnRzIG9u IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KPg0K Pj4gSGkgRGlubywNCj4+IFNvcnJ5LCBpIG1pc3VuZGVyc3Rvb2QgeW91LiBJIHRoaW5rIFZYTEFO LUdQRSBjYW4gZGVmaW5lIGEgbmV3IFVEUCBwb3J0IGFuZCBhIG5ldyBkYXRhIGZvcm1hdCwgUCBi aXQNCj4NCj4gTm8gd29ycmllcy4NCj4NCj4+IGluIFZYTEFOLUdQRSBzZWVtcyB0byBoYXZlIG5v IGFueSB2YWx1ZS4gQXMgZm9yIGJhc2ljIGludGVyLXN1Ym5ldCBsYXllciAzIGNvbW11bmljYXRp b24gYW5kIGludHJhLXN1Ym5ldCBsYXllciAyIGNvbW11bmljYXRpb24gYmV0d2VlbiBOVkVzLCBj dXJyZW50IE5WR1JFLCBWWExBTiBhbmQgTElTUCBoYXZlIGFscmVhZHkgc3VwcG9ydGVkLA0KPg0K PiBWWExBTiBzdXBwb3J0cyBMMiBvdmVybGF5cyBzaW5jZSBpdHMgZ29hbCBpcyB0byBleHRlbmQg c3VibmV0cy4gTElTUCBzdXBwb3J0cyBMMyBvdmVybGF5cyBzbyBpdCBhc3N1bWVzIHN1Ym5ldHMg YXJlIGxvY2FsICh0byB0aGUgeFRSKSBqdXN0IGxpa2UgaW4gYSByb3V0ZWQgbmV0d29yay4gTlZH UkUgY2FuIGJlIGEgY29tYm8uDQo+DQo+PiBOVkdSRSxWWExBTixMSVNQIGFuZCBWWExBTi1HUEUg Y2FuIGJlIGh5YnJpZCB1c2VkIHRvIGZvcm0gYSBOVk8zIG5ldHdvcmsgaWYgb25seSBiYXNpYyBs YXllciAzIGFuZA0KPg0KPiBUaGVyZSBpcyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBlbmNhcHN1 bGF0aW9uIGhlYWRlciAod2hpY2ggaXMgY2FsbGVkIFZYTEFOLUdQRSkgc28gaXQgY2FuIHN1cHBv cnQsIG1vc3QgaW1wb3J0YW50bHkgTlNILiBUaGF0IGNoYW5nZSBhbHNvIGdpdmVzIFZYTEFOIHRv IHN1cHBvcnQgZW5jYXBzdWxhdGluZyBsYXllci0yIElQdjQgYW5kIElQdjYsIHdoaWNoIGlzIGR1 cGxpY2F0ZSBmdW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUgc28gc2lt aWxhciwgaXQgcmVhbGx5IGRvZW5zJ3QgbWF0dGVyLg0KPg0KPiBIb3dldmVyLCB0aGUgUC1iaXQg aXMgbm90IG5lZWRlZCBmb3IgYW55dGhpbmcgbmV3IGluIExJU1AgYW5kIHRoZSBPQU0tYml0IGlz IG5vdCBuZWVkZWQgaW4gTElTUCBzaW5jZSBMSVNQIGhhcyBkaWZmZXJlbnQgVURQIHBvcnQgbnVt YmVyICg0MzQyKSBmb3IgY29udHJvbC1wYWNrZXRzLiBWWExBTiBkb2VzIG5vdCBoYXZlIGEgd2Vs bCBkZWZpbmVkIGNvbnRyb2wgcHJvdG9jb2wgc28gdGhlIGRhdGEtcGxhbmUgaGFzIHRvIGVzY2Fw ZSBvdXQgY29udHJvbC1wbGFuZSBwYWtjZXRzIHdoZXJlIHRoZSBmaXJzdCBvbmUgaXMgdGhpcyBu ZXcgT0FNIG1lc3NhZ2UuDQo+DQo+PiBsYXllciAyIGZvcndhcmRpbmcgcHJvY2VzcyBleGlzdHMu IEFzIGZvciBzb21lIGV4dHJhIGZ1bmN0aW9ucyBvZiBPQU0sIHNlcnZpY2UgY2hhaW5pbmcsYW5k IGV0YywgIG9ubHkgVlhMQU4tR1BFIGNhbiBzdXBwb3J0LCBwdXJlIFZYTEFOLUdQRSBuZXR3b3Jr IHNob3VsZCBiZSB1c2VkIGluIHRoZXNlIGNhc2VzLg0KPj4gVGhhbmtzDQo+PiB3ZWlndW8NCj4N Cj4gUmlnaHQsIGFncmVlLg0KPg0KPiBEaW5vDQo+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ILeivP7IyzogRGlubyBGYXJpbmFjY2kgW2Zh cmluYWNjaUBnbWFpbC5jb21dDQo+PiC3osvNyrG85DogMjAxNMTqN9TCMjjI1SAyMToxNQ0KPj4g ytW8/sjLOiBIYW93ZWlndW8NCj4+ILOty806IFRvbSBIZXJiZXJ0OyBEYXZpZCBNZWxtYW47IG52 bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3QNCj4+INb3zOI6IFJlOiC08Li0OiBb bnZvM10gQ29tbWVudHMgb24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4t dnhsYW4tZ3BlLTAzDQo+Pg0KPj4+IE9uIEp1bCAyOCwgMjAxNCwgYXQgNzoyNCBBTSwgSGFvd2Vp Z3VvIDxoYW93ZWlndW9AaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiBBYm91dCBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5LCBpIGFsc28gYWdyZWUgd2l0aCBEaW5vLiBWWExBTi1HUEUgc2hvdWxk IGZvY3VzIG9uICB0aGUgVlhMQU4tR1BFIGhlYWRlciBhbmQgcmVxdWlyZXMgdGhlIGFzc2lnbm1l bnQgb2YgYSBuZXcgVURQIHBvcnQsIHRoZSBkYXRhIGZvcm1hdCBkb24ndCBuZWVkIGNvbnNpZGVy IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBWWExBTiBoZWFkZXIuIEkNCj4+DQo+PiBJIHdh bnQgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHN1cHBvcnRpbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0 eSBpcyB2ZXJ5IGltcG9ydGFudCBzaW5jZSBWWExBTi1wb3J0LTQ3ODkgaXMgc3VwcG9ydGVkIGlu IHZhcmlvdXMgY2hpcHMgYWxyZWFkeS4NCj4+DQo+PiBEaW5v From nobody Tue Jul 29 23:40:27 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADE21A0418; Tue, 29 Jul 2014 23:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.999 X-Spam-Level: **** X-Spam-Status: No, score=4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001] autolearn=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 Y8YuMiV2LvJe; Tue, 29 Jul 2014 23:40:22 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BF91A03D4; Tue, 29 Jul 2014 23:40:21 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 5603F2AA0F; Wed, 30 Jul 2014 06:40:16 +0000 (GMT) Date: Tue, 29 Jul 2014 23:40:19 -0700 From: Marc Binderberger To: Haoweiguo Message-ID: <20140729234019087723.ceceb885@sniff.de> In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/dkFlrK97c2W3HAkaaF3WCf2YLs8 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Dino Farinacci , Tom Herbert Subject: Re: [nvo3] =?gb2312?b?tPC4tDogtPC4tDogQ29tbWVudHMgb24gaHR0cDovL3Rv?= =?gb2312?b?b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAz?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 06:40:24 -0000 SGVsbG8gV2VpZ3VvLA0KDQpJIHdvdWxkIHNheSB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgaWYg eW91ciAibGF5ZXItMyIgc2VydmljZSBpcyBhY3R1YWxseSBhIA0KbGF5ZXItMiBFdGhlcm5l dCBmcmFtZSB3aXRoIHRoZSBkZXN0aW5hdGlvbiBNQUMgb2YgdGhlIGVuY2Fwc3VsYXRlZCBw YWNrZXQgDQpiZWluZyBpZGVudGljYWwgd2l0aCB0aGUgTUFDIG9mIHRoZSBkZWNhcHN1bGF0 aW5nIHN5c3RlbSwgY29tcGFyZWQgdG8gYSANCmxheWVyLTMgc2VydmljZSB3aGVyZSB5b3Vy IHdob2xlIHByb2Nlc3Npbmcgc3RheXMgc29sZWx5IGluIHRoZSBsYXllci0zLCBubyANCk1B QyBpbnZvbHZlZC4NCg0KSWYgSSB3YW50IHRvIGRlZmluZSBhIGxheWVyLTMgZW5jYXBzdWxh dGlvbiAobGlrZSBMSVNQLCBsaWtlIHRoZSBwcm9wb3NlZCANClZ4TEFOLWdwZSB3aXRoIElQ djQvdjYgYXMgcHJvdG9jb2wpIHRoZW4gaGF2aW5nIGFueSBsYXllci0yIGluIHRoZSBwcm9j ZXNzIA0Kc2VlbXMgYSBiaXQgIm9kZCIuIFdvcnNlLCB0aGUgaW52b2x2ZWQgc3lzdGVtcyBt YXkgbm90IGhhdmUgdGhpcyBsYXllci0yIA0KbG9naWMuIExJU1AgZm9yIGV4YW1wbGUgaXMg b2Z0ZW4gdXNlZCBpbiB0aGUgV0FOLCBldmVuIHdoZW4gc29tZSANCmVuY2Fwc3VsYXRvci9k ZWNhcHN1bGF0b3IgYXJlIERDIHN3aXRjaGVzLiBTb21lIG9mIHRoZXNlIFdBTiBzeXN0ZW1z IG1heSBiZSANCnB1cmUgSVB2NC92NiByb3V0ZXJzLg0KDQoNCkluIG90aGVyIHdvcmRzOiBo YXZpbmcgYm90aCBhIGxheWVyLTIgKFZ4TEFOKSBhbmQgYSBsYXllci0zIChMSVNQKSANCmVu Y2Fwc3VsYXRpb24gbWFrZXMgZ29vZCBzZW5zZS4gVGhlIHF1ZXN0aW9uIGlzOiBzaGFsbCB3 ZSBrZWVwIGl0IHNlcGFyYXRlZCANCmFzIGl0IGlzIHRvZGF5IGFzICJMSVNQIiBhbmQgIlZ4 TEFOIiBvciBjb21iaW5lIHRoZSAoZXhwZW5zaXZlKSBtdWx0aXBsZSBkYXRhIA0KcGxhbmVz IGludG8gb25lIFZ4TEFOLWdwZS4NCg0KDQpSZWdhcmRzLCBNYXJjDQoNCg0KDQoNCg0KT24g V2VkLCAzMCBKdWwgMjAxNCAwMzoxNToxOSArMDAwMCwgSGFvd2VpZ3VvIHdyb3RlOg0KPiBI aSBEaW5vLA0KPiBWWExBTiBjYW4gdXNlIGEgdW5pZmllZCBlbmNhcHN1bGF0aW9uIHRvIHJl YWxpemUgYm90aCBpbnRyYS1zdWJuZXQgbGF5ZXIgMiANCj4gdHJhZmZpYyBmb3J3YXJkaW5n IGFuZCBpbnRlci1zdWJuZXQgbGF5ZXIgMyB0cmFmZmljIGZvcndhcmRpbmcgYXQgdGhlIHNh bWUgDQo+IHRpbWUsIGlubmVyIGRlc3RpbmF0aW9uIE1BQyBpcyB1c2VkIHRvIGRpZmZlcmVu Y2lhdGUgbGF5ZXIgMiB0cmFmZmljIGZyb20gDQo+IGxheWVyIDMgdHJhZmZpYy4gDQo+IExJ U1AgdXNlcyB0d28gZGlmZmVyZW50IGVuY2Fwc3VsYXRpb25zIGZvciBpbnRyYS1zdWJuZXQg bGF5ZXIgMiB0cmFmZmljIA0KPiBmb3J3YXJkaW5nIGFuZCBpbnRlci1zdWJuZXQgbGF5ZXIg MyB0cmFmZmljIGZvcndhcmRpbmcsIFVEUCBwb3J0IGlzIHVzZWQgdG8gDQo+IGRpZmZlcmVu Y2lhdGUgbGF5ZXIgMiB0cmFmZmljIGZyb20gbGF5ZXIgMyB0cmFmZmljLg0KPiBGcm9tIHRo ZW9yZXRpY2FsIHBlcnNwZWN0aXZlLCAgYm90aCB0aGUgdHdvIHNvbHV0aW9ucyBhcmUgYXBw bGljYWJsZS4gRnJvbSANCj4gY29tbWVyY2lhbCB1c2UgcGVyc3BlY3RpdmUsIHRoZSBmb3Jt ZXIodW5pZmllZCBlbmNhcCBmb3IgYm90aCBsYXllciAyIGFuZCANCj4gbGF5ZXIgMykgc2Vl bXMgdG8gYmUgbW9yZSBwb3B1bGFyIGN1cnJlbnRseS4NCj4gVGhhbmtzDQo+IHdlaWd1bw0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7Iyzog RGlubyBGYXJpbmFjY2kgW2ZhcmluYWNjaUBnbWFpbC5jb21dDQo+ILeiy83KsbzkOiAyMDE0 xOo31MIyOcjVIDIwOjE4DQo+IMrVvP7IyzogSGFvd2VpZ3VvDQo+ILOty806IERhdmlkIE1l bG1hbjsgbnZvM0BpZXRmLm9yZzsgTElTUCBtYWlsaW5nIGxpc3QgbGlzdDsgVG9tIEhlcmJl cnQNCj4g1vfM4jogUmU6ILTwuLQ6IFtudm8zXSBDb21tZW50cyBvbiANCj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQo+IA0KPiBJIHVu ZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHNheWluZyBidXQgaXQgY29tZXMgZG93biB0byB3aGF0 IHRoZSBlbmNhcHN1bGF0b3IgDQo+IGlzIGVuY2Fwc3VsYXRpbmcuIElmIHRoZSBwYWNrZXQg aXQgaXMgZW5jYXBzdWxhdGluZyBpcyBhbiBMMiBmcmFtZSB0aGVuIHRoZSANCj4gZW5jYXBz dWxhdG9yIGlzIHN1cHBvcnRpbmcgYSBsYXllci0yIG92ZXJsYXkgc2VydmljZS4gT3RoZXJ3 aXNlIGl0IGlzIGEgYSANCj4gbGF5ZXItMyBvdmVybGF5IHNlcnZpY2UuDQo+IA0KPiBJZiB0 aGUgZGVzdCBNQUMgSXMgdG8gdGhlIGVuY2Fwc3VsYXRvciB0aGF0IE1BQyBoZWFkZXIgaXMg c3RyaXBwZWQgYmVmb3JlIGEgDQo+IGxheWVyLTMgZm9yd2FyZGluZyBkZWNpc2lvbiBpcyBt YWRlLiBUaGVuLCBhdCB3aGljaCB0aW1lIHRoZSBwYWNrZXQgaXMgDQo+IGZvcndhcmRlZCBu YXRpdmVseSBvciBlbmNhcHN1bGF0ZWQuDQo+IA0KPiBJZiB0aGUgZGVzdCBNQUMgaXMgbm90 IHRoZSBlbmNhcHN1bGF0b3IncyBhZGRyZXNzLCB0aGVuIHRoZSBNQUMgaGVhZGVyIA0KPiBz dGF5cyB3aXRoIHRoZSBwYWNrZXQvZnJhbWUgYW5kIHRoZW4gZW5jYXBzdWxhdGVkLg0KPiAN Cj4gVGhlIGZvcm1lciBpcyBhIGxheWVyLTMgb3ZlcmxheSBhbmQgdGhlIGxhdHRlciBpcyBh IGxheWVyLTIgb3ZlcmxheSB3aGVyZSANCj4gYm90aCBjYW4gYmUgc3VwcG9ydGVkIGF0IHRo ZSBzYW1lIHRpbWUgaW4gb25lIGVuY2Fwc3VsYXRvciBkZXZpY2UuDQo+IA0KPiBUaGUgZm9y bWVyIGlzIExJU1AgZW5jYXBzdWxhdGlvbiBhbmQgdGhlIGxhdHRlciBpcyBWWExBTiBlbmNh cHN1bGF0aW9uLg0KPiANCj4gV2l0aCBWWExBTi1HUEUgYm90aCBjYXNlcyBjYW4gYmUgc3Vw cG9ydGVkIChhbmQgbW9zdCBpbXBvcnRhbnRseSB3aXRoIGEgDQo+IHNpbmdsZSB1bmlmaWVk IGNvbnRyb2wtcGxhbmUpLg0KPiANCj4gU28gSSBiZWxpZXZlIFZYTEFOLUdQRSBjb3VsZCBi ZSB1c2VmdWwgeWV0IHJlZHVuZGFudCBidXQgTElTUCByZXF1aXJlcyBubyANCj4gY2hhbmdl cyAoaWYgTElTUCBzdXBwb3J0cyAgTDIgd2hpY2ggaXMgZG9jdW1lbnRlZCBpbiANCj4gZHJh ZnQtc21pdGgtbGlzcC1sYXllci0yIHVzaW5nIGEgZGlmZmVyZW50IHBvcnQgbnVtYmVyKS4N Cj4gDQo+IERpbm8NCj4gDQo+PiBPbiBKdWwgMjksIDIwMTQsIGF0IDM6NTggQU0sIEhhb3dl aWd1byA8aGFvd2VpZ3VvQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBEaW5vLA0K Pj4gVGhhbmtzIGZvciB5b3VyIGRldGFpbCBjb21tZW50cy4gIEFzIGZvciBjdXJyZW50IFZY TEFOIGVuY2Fwc3VsYXRpb24sIHBscyANCj4+IHNlZSBteSBjb21tZW50cyBpbmxpbmUgd2l0 aCBbd2VpZ3VvXSBiZWxvdy4NCj4+IA0KPj4gVGhlcmUgaXMgbW90aXZhdGlvbiB0byBleHRl bmQgYW4gZW5jYXBzdWxhdGlvbiBoZWFkZXIgKHdoaWNoIGlzIGNhbGxlZCANCj4+IFZYTEFO LUdQRSkgc28gaXQgY2FuIHN1cHBvcnQsIG1vc3QgaW1wb3J0YW50bHkgTlNILiBUaGF0IGNo YW5nZSBhbHNvIGdpdmVzIA0KPj4gVlhMQU4gdG8gc3VwcG9ydCBlbmNhcHN1bGF0aW5nIGxh eWVyLTIgSVB2NCBhbmQgSVB2Niwgd2hpY2ggaXMgZHVwbGljYXRlIA0KPj4gZnVuY3Rpb25h bGl0eSBvZiBMSVNQLiBCdXQgdGhlIGhlYWRlcnMgYXJlIHNvIHNpbWlsYXIsIGl0IHJlYWxs eSBkb2Vucyd0IA0KPj4gbWF0dGVyLg0KPj4gDQo+PiBbd2VpZ3VvXTogWWVzLCBhbiBuZXcg ZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgDQo+ PiBOU0guIEJ1dCBhcyBmb3IgSVB2NCBhbmQgSVB2NiwgaSB0aGluayBjdXJyZW50IFZYTEFO IGFscmVhZHkgc3VwcG9ydGVkLiAgDQo+PiBGb3IgdGhlIGxheWVyIDMgaW50ZXItc3VibmV0 IHRyYWZmaWMgZnJvbSBOVkUxIHRvIE5WRTIsIGlubmVyIGRlc3RpbmF0aW9uIA0KPj4gTUFD IGlzIHRoZSBnYXRld2F5IGludGVyZmFjZSBNQUMgYXQgTlZFMi4gIEZvciB0aGUgbGF5ZXIg MiBpbnRyYS1zdWJuZXQgDQo+PiB0cmFmZmljIGZyb20gTlZFMSB0byBOVkUyLCAgaW5uZXIg ZGVzdGluYXRpb24gTUFDIGlzIHRoZSBkZXN0aW5hdGlvbiBUUydzIA0KPj4gTUFDLiBXaGVu IE5WRTIgcmVjZWl2ZXMgVlhMQU4gZW5jYXBzdWxhdGVkIHRyYWZmaWMgZnJvbSBOVkUxLCBp bm5lciANCj4+IGRlc3RpbmF0aW9uIE1BQyBjYW4gYmUgdXNlZCB0byBkaWZmZXJlbnRpYXRl IGxheWVyIDIgdHJhZmZpYyBmcm9tIGxheWVyIDMgDQo+PiB0cmFmZmljLiBWWExBTiBkaXN0 cmlidXRlZCBsYXllciAzIGdhdGV3YXkgY2FuIGJlIHJlYWxpemVkIHRocm91Z2ggdGhlIA0K Pj4gbWVjaGFuaXNtLCBOVkUgY2FuIGZvcndhcmQgYm90aCBpbnRyYS1zdWJuZXQgbGF5ZXIg MiB0cmFmZmljIGFuZCANCj4+IGludGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgYXQgdGhl IHNhbWUgdGltZS4NCj4+IA0KPj4gVGhhbmtzDQo+PiB3ZWlndW8NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ILeivP7IyzogRGlubyBGYXJpbmFj Y2kgW2ZhcmluYWNjaUBnbWFpbC5jb21dDQo+PiC3osvNyrG85DogMjAxNMTqN9TCMjjI1SAy MjoxNw0KPj4gytW8/sjLOiBIYW93ZWlndW8NCj4+ILOty806IERhdmlkIE1lbG1hbjsgbnZv M0BpZXRmLm9yZzsgTElTUCBtYWlsaW5nIGxpc3QgbGlzdDsgVG9tIEhlcmJlcnQNCj4+INb3 zOI6IFJlOiBbbnZvM10gQ29tbWVudHMgb24gDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1xdWlubi12eGxhbi1ncGUtMDMNCj4+IA0KPj4+IEhpIERpbm8sDQo+Pj4g U29ycnksIGkgbWlzdW5kZXJzdG9vZCB5b3UuIEkgdGhpbmsgVlhMQU4tR1BFIGNhbiBkZWZp bmUgYSBuZXcgVURQIHBvcnQgDQo+Pj4gYW5kIGEgbmV3IGRhdGEgZm9ybWF0LCBQIGJpdA0K Pj4gDQo+PiBObyB3b3JyaWVzLg0KPj4gDQo+Pj4gaW4gVlhMQU4tR1BFIHNlZW1zIHRvIGhh dmUgbm8gYW55IHZhbHVlLiBBcyBmb3IgYmFzaWMgaW50ZXItc3VibmV0IGxheWVyIA0KPj4+ IDMgY29tbXVuaWNhdGlvbiBhbmQgaW50cmEtc3VibmV0IGxheWVyIDIgY29tbXVuaWNhdGlv biBiZXR3ZWVuIE5WRXMsIA0KPj4+IGN1cnJlbnQgTlZHUkUsIFZYTEFOIGFuZCBMSVNQIGhh dmUgYWxyZWFkeSBzdXBwb3J0ZWQsDQo+PiANCj4+IFZYTEFOIHN1cHBvcnRzIEwyIG92ZXJs YXlzIHNpbmNlIGl0cyBnb2FsIGlzIHRvIGV4dGVuZCBzdWJuZXRzLiBMSVNQIA0KPj4gc3Vw cG9ydHMgTDMgb3ZlcmxheXMgc28gaXQgYXNzdW1lcyBzdWJuZXRzIGFyZSBsb2NhbCAodG8g dGhlIHhUUikganVzdCANCj4+IGxpa2UgaW4gYSByb3V0ZWQgbmV0d29yay4gTlZHUkUgY2Fu IGJlIGEgY29tYm8uDQo+PiANCj4+PiBOVkdSRSxWWExBTixMSVNQIGFuZCBWWExBTi1HUEUg Y2FuIGJlIGh5YnJpZCB1c2VkIHRvIGZvcm0gYSBOVk8zIG5ldHdvcmsgDQo+Pj4gaWYgb25s eSBiYXNpYyBsYXllciAzIGFuZA0KPj4gDQo+PiBUaGVyZSBpcyBtb3RpdmF0aW9uIHRvIGV4 dGVuZCBhbiBlbmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2ggaXMgY2FsbGVkIA0KPj4gVlhM QU4tR1BFKSBzbyBpdCBjYW4gc3VwcG9ydCwgbW9zdCBpbXBvcnRhbnRseSBOU0guIFRoYXQg Y2hhbmdlIGFsc28gZ2l2ZXMgDQo+PiBWWExBTiB0byBzdXBwb3J0IGVuY2Fwc3VsYXRpbmcg bGF5ZXItMiBJUHY0IGFuZCBJUHY2LCB3aGljaCBpcyBkdXBsaWNhdGUgDQo+PiBmdW5jdGlv bmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUgc28gc2ltaWxhciwgaXQgcmVh bGx5IGRvZW5zJ3QgDQo+PiBtYXR0ZXIuDQo+PiANCj4+IEhvd2V2ZXIsIHRoZSBQLWJpdCBp cyBub3QgbmVlZGVkIGZvciBhbnl0aGluZyBuZXcgaW4gTElTUCBhbmQgdGhlIE9BTS1iaXQg DQo+PiBpcyBub3QgbmVlZGVkIGluIExJU1Agc2luY2UgTElTUCBoYXMgZGlmZmVyZW50IFVE UCBwb3J0IG51bWJlciAoNDM0MikgZm9yIA0KPj4gY29udHJvbC1wYWNrZXRzLiBWWExBTiBk b2VzIG5vdCBoYXZlIGEgd2VsbCBkZWZpbmVkIGNvbnRyb2wgcHJvdG9jb2wgc28gDQo+PiB0 aGUgZGF0YS1wbGFuZSBoYXMgdG8gZXNjYXBlIG91dCBjb250cm9sLXBsYW5lIHBha2NldHMg d2hlcmUgdGhlIGZpcnN0IG9uZSANCj4+IGlzIHRoaXMgbmV3IE9BTSBtZXNzYWdlLg0KPj4g DQo+Pj4gbGF5ZXIgMiBmb3J3YXJkaW5nIHByb2Nlc3MgZXhpc3RzLiBBcyBmb3Igc29tZSBl eHRyYSBmdW5jdGlvbnMgb2YgT0FNLCANCj4+PiBzZXJ2aWNlIGNoYWluaW5nLGFuZCBldGMs ICBvbmx5IFZYTEFOLUdQRSBjYW4gc3VwcG9ydCwgcHVyZSBWWExBTi1HUEUgDQo+Pj4gbmV0 d29yayBzaG91bGQgYmUgdXNlZCBpbiB0aGVzZSBjYXNlcy4NCj4+PiBUaGFua3MNCj4+PiB3 ZWlndW8NCj4+IA0KPj4gUmlnaHQsIGFncmVlLg0KPj4gDQo+PiBEaW5vDQo+PiANCj4+PiAN Cj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gt6K8/sjLOiBEaW5vIEZhcmluYWNjaSBbZmFyaW5hY2NpQGdtYWlsLmNvbV0NCj4+PiC3 osvNyrG85DogMjAxNMTqN9TCMjjI1SAyMToxNQ0KPj4+IMrVvP7IyzogSGFvd2VpZ3VvDQo+ Pj4gs63LzTogVG9tIEhlcmJlcnQ7IERhdmlkIE1lbG1hbjsgbnZvM0BpZXRmLm9yZzsgTElT UCBtYWlsaW5nIGxpc3QgbGlzdA0KPj4+INb3zOI6IFJlOiC08Li0OiBbbnZvM10gQ29tbWVu dHMgb24gDQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhs YW4tZ3BlLTAzDQo+Pj4gDQo+Pj4+IE9uIEp1bCAyOCwgMjAxNCwgYXQgNzoyNCBBTSwgSGFv d2VpZ3VvIDxoYW93ZWlndW9AaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBBYm91 dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBpIGFsc28gYWdyZWUgd2l0aCBEaW5vLiBWWExB Ti1HUEUgc2hvdWxkIA0KPj4+PiBmb2N1cyBvbiAgdGhlIFZYTEFOLUdQRSBoZWFkZXIgYW5k IHJlcXVpcmVzIHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUCANCj4+Pj4gcG9ydCwgdGhl IGRhdGEgZm9ybWF0IGRvbid0IG5lZWQgY29uc2lkZXIgYmFja3dhcmQgY29tcGF0aWJpbGl0 eSB3aXRoIA0KPj4+PiBWWExBTiBoZWFkZXIuIEkNCj4+PiANCj4+PiBJIHdhbnQgdG8gbWFr ZSBpdCBjbGVhciB0aGF0IHN1cHBvcnRpbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyB2 ZXJ5IA0KPj4+IGltcG9ydGFudCBzaW5jZSBWWExBTi1wb3J0LTQ3ODkgaXMgc3VwcG9ydGVk IGluIHZhcmlvdXMgY2hpcHMgYWxyZWFkeS4NCj4+PiANCj4+PiBEaW5vDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG52bzMgbWFpbGlu ZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9udm8z From nobody Wed Jul 30 02:29:58 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB421B2A3D; Wed, 30 Jul 2014 02:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.348 X-Spam-Level: ** X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PqeJ9N4-XUy2; Wed, 30 Jul 2014 02:29:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7F31B2A25; Wed, 30 Jul 2014 02:29:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS25540; Wed, 30 Jul 2014 09:29:49 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Jul 2014 10:29:46 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 30 Jul 2014 17:29:42 +0800 From: Haoweiguo To: Marc Binderberger Thread-Topic: =?gb2312?B?W252bzNdILTwuLQ6ILTwuLQ6ICBDb21tZW50cyBvbiBodHRwOi8vdG9vbHMu?= =?gb2312?Q?ietf.org/html/draft-quinn-vxlan-gpe-03?= Thread-Index: AQHPq8UpZvCMYhqnVE2ZDwe/al7MtZu4UrtB Date: Wed, 30 Jul 2014 09:29:41 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> , <20140729234019087723.ceceb885@sniff.de> In-Reply-To: <20140729234019087723.ceceb885@sniff.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/gPpL7h2zurFQsGF4bDseemOU4Ak Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Dino Farinacci , Tom Herbert Subject: [nvo3] =?gb2312?b?tPC4tDogILTwuLQ6ILTwuLQ6ICBDb21tZW50cyBvbiBo?= =?gb2312?b?dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi12eGxhbi1n?= =?gb2312?b?cGUtMDM=?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 09:29:54 -0000 SGkgTWFyYywNCg0KVlhMQU4tR1BFIGhhdmUgbmV4dCBwcm90b2NvbCBmaWVsZCwgc28gaXQgY2Fu IGNvbWJpbmUgbXVsdGlwbGUgZGF0YSBwbGFuZXMgaW50byBvbmUgVlhMQU4tZ3BlLiBDdXJyZW50 bHkgaW5uZXIgZGVzdGluYXRpb24gTUFDIGNhbiBiZSB1c2VkIHRvIGRpc3Rpbmd1aXNoIGxheWVy IDIgYW5kIGxheWVyIDMgdHJhZmZpYyBhdCBlZ3Jlc3MgTlZFLg0KVGhhbmtzDQp3ZWlndW8NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogTWFyYyBCaW5k ZXJiZXJnZXIgW21hcmNAc25pZmYuZGVdDQq3osvNyrG85DogMjAxNMTqN9TCMzDI1SAxNDo0MA0K ytW8/sjLOiBIYW93ZWlndW8NCrOty806IERpbm8gRmFyaW5hY2NpOyBEYXZpZCBNZWxtYW47IG52 bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQrW98ziOiBS ZTogW252bzNdILTwuLQ6ILTwuLQ6ICBDb21tZW50cyBvbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1xdWlubi12eGxhbi1ncGUtMDMNCg0KSGVsbG8gV2VpZ3VvLA0KDQpJIHdvdWxk IHNheSB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgaWYgeW91ciAibGF5ZXItMyIgc2VydmljZSBpcyBh Y3R1YWxseSBhDQpsYXllci0yIEV0aGVybmV0IGZyYW1lIHdpdGggdGhlIGRlc3RpbmF0aW9uIE1B QyBvZiB0aGUgZW5jYXBzdWxhdGVkIHBhY2tldA0KYmVpbmcgaWRlbnRpY2FsIHdpdGggdGhlIE1B QyBvZiB0aGUgZGVjYXBzdWxhdGluZyBzeXN0ZW0sIGNvbXBhcmVkIHRvIGENCmxheWVyLTMgc2Vy dmljZSB3aGVyZSB5b3VyIHdob2xlIHByb2Nlc3Npbmcgc3RheXMgc29sZWx5IGluIHRoZSBsYXll ci0zLCBubw0KTUFDIGludm9sdmVkLg0KDQpJZiBJIHdhbnQgdG8gZGVmaW5lIGEgbGF5ZXItMyBl bmNhcHN1bGF0aW9uIChsaWtlIExJU1AsIGxpa2UgdGhlIHByb3Bvc2VkDQpWeExBTi1ncGUgd2l0 aCBJUHY0L3Y2IGFzIHByb3RvY29sKSB0aGVuIGhhdmluZyBhbnkgbGF5ZXItMiBpbiB0aGUgcHJv Y2Vzcw0Kc2VlbXMgYSBiaXQgIm9kZCIuIFdvcnNlLCB0aGUgaW52b2x2ZWQgc3lzdGVtcyBtYXkg bm90IGhhdmUgdGhpcyBsYXllci0yDQpsb2dpYy4gTElTUCBmb3IgZXhhbXBsZSBpcyBvZnRlbiB1 c2VkIGluIHRoZSBXQU4sIGV2ZW4gd2hlbiBzb21lDQplbmNhcHN1bGF0b3IvZGVjYXBzdWxhdG9y IGFyZSBEQyBzd2l0Y2hlcy4gU29tZSBvZiB0aGVzZSBXQU4gc3lzdGVtcyBtYXkgYmUNCnB1cmUg SVB2NC92NiByb3V0ZXJzLg0KDQoNCkluIG90aGVyIHdvcmRzOiBoYXZpbmcgYm90aCBhIGxheWVy LTIgKFZ4TEFOKSBhbmQgYSBsYXllci0zIChMSVNQKQ0KZW5jYXBzdWxhdGlvbiBtYWtlcyBnb29k IHNlbnNlLiBUaGUgcXVlc3Rpb24gaXM6IHNoYWxsIHdlIGtlZXAgaXQgc2VwYXJhdGVkDQphcyBp dCBpcyB0b2RheSBhcyAiTElTUCIgYW5kICJWeExBTiIgb3IgY29tYmluZSB0aGUgKGV4cGVuc2l2 ZSkgbXVsdGlwbGUgZGF0YQ0KcGxhbmVzIGludG8gb25lIFZ4TEFOLWdwZS4NCg0KDQpSZWdhcmRz LCBNYXJjDQoNCg0KDQoNCg0KT24gV2VkLCAzMCBKdWwgMjAxNCAwMzoxNToxOSArMDAwMCwgSGFv d2VpZ3VvIHdyb3RlOg0KPiBIaSBEaW5vLA0KPiBWWExBTiBjYW4gdXNlIGEgdW5pZmllZCBlbmNh cHN1bGF0aW9uIHRvIHJlYWxpemUgYm90aCBpbnRyYS1zdWJuZXQgbGF5ZXIgMg0KPiB0cmFmZmlj IGZvcndhcmRpbmcgYW5kIGludGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgZm9yd2FyZGluZyBh dCB0aGUgc2FtZQ0KPiB0aW1lLCBpbm5lciBkZXN0aW5hdGlvbiBNQUMgaXMgdXNlZCB0byBkaWZm ZXJlbmNpYXRlIGxheWVyIDIgdHJhZmZpYyBmcm9tDQo+IGxheWVyIDMgdHJhZmZpYy4NCj4gTElT UCB1c2VzIHR3byBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbnMgZm9yIGludHJhLXN1Ym5ldCBsYXll ciAyIHRyYWZmaWMNCj4gZm9yd2FyZGluZyBhbmQgaW50ZXItc3VibmV0IGxheWVyIDMgdHJhZmZp YyBmb3J3YXJkaW5nLCBVRFAgcG9ydCBpcyB1c2VkIHRvDQo+IGRpZmZlcmVuY2lhdGUgbGF5ZXIg MiB0cmFmZmljIGZyb20gbGF5ZXIgMyB0cmFmZmljLg0KPiBGcm9tIHRoZW9yZXRpY2FsIHBlcnNw ZWN0aXZlLCAgYm90aCB0aGUgdHdvIHNvbHV0aW9ucyBhcmUgYXBwbGljYWJsZS4gRnJvbQ0KPiBj b21tZXJjaWFsIHVzZSBwZXJzcGVjdGl2ZSwgdGhlIGZvcm1lcih1bmlmaWVkIGVuY2FwIGZvciBi b3RoIGxheWVyIDIgYW5kDQo+IGxheWVyIDMpIHNlZW1zIHRvIGJlIG1vcmUgcG9wdWxhciBjdXJy ZW50bHkuDQo+IFRoYW5rcw0KPiB3ZWlndW8NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiC3orz+yMs6IERpbm8gRmFyaW5hY2NpIFtmYXJpbmFjY2lAZ21haWwu Y29tXQ0KPiC3osvNyrG85DogMjAxNMTqN9TCMjnI1SAyMDoxOA0KPiDK1bz+yMs6IEhhb3dlaWd1 bw0KPiCzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0 IGxpc3Q7IFRvbSBIZXJiZXJ0DQo+INb3zOI6IFJlOiC08Li0OiBbbnZvM10gQ29tbWVudHMgb24N Cj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQo+ DQo+IEkgdW5kZXJzdGFuZCB3aGF0IHlvdSBhcmUgc2F5aW5nIGJ1dCBpdCBjb21lcyBkb3duIHRv IHdoYXQgdGhlIGVuY2Fwc3VsYXRvcg0KPiBpcyBlbmNhcHN1bGF0aW5nLiBJZiB0aGUgcGFja2V0 IGl0IGlzIGVuY2Fwc3VsYXRpbmcgaXMgYW4gTDIgZnJhbWUgdGhlbiB0aGUNCj4gZW5jYXBzdWxh dG9yIGlzIHN1cHBvcnRpbmcgYSBsYXllci0yIG92ZXJsYXkgc2VydmljZS4gT3RoZXJ3aXNlIGl0 IGlzIGEgYQ0KPiBsYXllci0zIG92ZXJsYXkgc2VydmljZS4NCj4NCj4gSWYgdGhlIGRlc3QgTUFD IElzIHRvIHRoZSBlbmNhcHN1bGF0b3IgdGhhdCBNQUMgaGVhZGVyIGlzIHN0cmlwcGVkIGJlZm9y ZSBhDQo+IGxheWVyLTMgZm9yd2FyZGluZyBkZWNpc2lvbiBpcyBtYWRlLiBUaGVuLCBhdCB3aGlj aCB0aW1lIHRoZSBwYWNrZXQgaXMNCj4gZm9yd2FyZGVkIG5hdGl2ZWx5IG9yIGVuY2Fwc3VsYXRl ZC4NCj4NCj4gSWYgdGhlIGRlc3QgTUFDIGlzIG5vdCB0aGUgZW5jYXBzdWxhdG9yJ3MgYWRkcmVz cywgdGhlbiB0aGUgTUFDIGhlYWRlcg0KPiBzdGF5cyB3aXRoIHRoZSBwYWNrZXQvZnJhbWUgYW5k IHRoZW4gZW5jYXBzdWxhdGVkLg0KPg0KPiBUaGUgZm9ybWVyIGlzIGEgbGF5ZXItMyBvdmVybGF5 IGFuZCB0aGUgbGF0dGVyIGlzIGEgbGF5ZXItMiBvdmVybGF5IHdoZXJlDQo+IGJvdGggY2FuIGJl IHN1cHBvcnRlZCBhdCB0aGUgc2FtZSB0aW1lIGluIG9uZSBlbmNhcHN1bGF0b3IgZGV2aWNlLg0K Pg0KPiBUaGUgZm9ybWVyIGlzIExJU1AgZW5jYXBzdWxhdGlvbiBhbmQgdGhlIGxhdHRlciBpcyBW WExBTiBlbmNhcHN1bGF0aW9uLg0KPg0KPiBXaXRoIFZYTEFOLUdQRSBib3RoIGNhc2VzIGNhbiBi ZSBzdXBwb3J0ZWQgKGFuZCBtb3N0IGltcG9ydGFudGx5IHdpdGggYQ0KPiBzaW5nbGUgdW5pZmll ZCBjb250cm9sLXBsYW5lKS4NCj4NCj4gU28gSSBiZWxpZXZlIFZYTEFOLUdQRSBjb3VsZCBiZSB1 c2VmdWwgeWV0IHJlZHVuZGFudCBidXQgTElTUCByZXF1aXJlcyBubw0KPiBjaGFuZ2VzIChpZiBM SVNQIHN1cHBvcnRzICBMMiB3aGljaCBpcyBkb2N1bWVudGVkIGluDQo+IGRyYWZ0LXNtaXRoLWxp c3AtbGF5ZXItMiB1c2luZyBhIGRpZmZlcmVudCBwb3J0IG51bWJlcikuDQo+DQo+IERpbm8NCj4N Cj4+IE9uIEp1bCAyOSwgMjAxNCwgYXQgMzo1OCBBTSwgSGFvd2VpZ3VvIDxoYW93ZWlndW9AaHVh d2VpLmNvbT4gd3JvdGU6DQo+Pg0KPj4gSGkgRGlubywNCj4+IFRoYW5rcyBmb3IgeW91ciBkZXRh aWwgY29tbWVudHMuICBBcyBmb3IgY3VycmVudCBWWExBTiBlbmNhcHN1bGF0aW9uLCBwbHMNCj4+ IHNlZSBteSBjb21tZW50cyBpbmxpbmUgd2l0aCBbd2VpZ3VvXSBiZWxvdy4NCj4+DQo+PiBUaGVy ZSBpcyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBlbmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2gg aXMgY2FsbGVkDQo+PiBWWExBTi1HUEUpIHNvIGl0IGNhbiBzdXBwb3J0LCBtb3N0IGltcG9ydGFu dGx5IE5TSC4gVGhhdCBjaGFuZ2UgYWxzbyBnaXZlcw0KPj4gVlhMQU4gdG8gc3VwcG9ydCBlbmNh cHN1bGF0aW5nIGxheWVyLTIgSVB2NCBhbmQgSVB2Niwgd2hpY2ggaXMgZHVwbGljYXRlDQo+PiBm dW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUgc28gc2ltaWxhciwgaXQg cmVhbGx5IGRvZW5zJ3QNCj4+IG1hdHRlci4NCj4+DQo+PiBbd2VpZ3VvXTogWWVzLCBhbiBuZXcg ZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQNCj4+IE5T SC4gQnV0IGFzIGZvciBJUHY0IGFuZCBJUHY2LCBpIHRoaW5rIGN1cnJlbnQgVlhMQU4gYWxyZWFk eSBzdXBwb3J0ZWQuDQo+PiBGb3IgdGhlIGxheWVyIDMgaW50ZXItc3VibmV0IHRyYWZmaWMgZnJv bSBOVkUxIHRvIE5WRTIsIGlubmVyIGRlc3RpbmF0aW9uDQo+PiBNQUMgaXMgdGhlIGdhdGV3YXkg aW50ZXJmYWNlIE1BQyBhdCBOVkUyLiAgRm9yIHRoZSBsYXllciAyIGludHJhLXN1Ym5ldA0KPj4g dHJhZmZpYyBmcm9tIE5WRTEgdG8gTlZFMiwgIGlubmVyIGRlc3RpbmF0aW9uIE1BQyBpcyB0aGUg ZGVzdGluYXRpb24gVFMncw0KPj4gTUFDLiBXaGVuIE5WRTIgcmVjZWl2ZXMgVlhMQU4gZW5jYXBz dWxhdGVkIHRyYWZmaWMgZnJvbSBOVkUxLCBpbm5lcg0KPj4gZGVzdGluYXRpb24gTUFDIGNhbiBi ZSB1c2VkIHRvIGRpZmZlcmVudGlhdGUgbGF5ZXIgMiB0cmFmZmljIGZyb20gbGF5ZXIgMw0KPj4g dHJhZmZpYy4gVlhMQU4gZGlzdHJpYnV0ZWQgbGF5ZXIgMyBnYXRld2F5IGNhbiBiZSByZWFsaXpl ZCB0aHJvdWdoIHRoZQ0KPj4gbWVjaGFuaXNtLCBOVkUgY2FuIGZvcndhcmQgYm90aCBpbnRyYS1z dWJuZXQgbGF5ZXIgMiB0cmFmZmljIGFuZA0KPj4gaW50ZXItc3VibmV0IGxheWVyIDMgdHJhZmZp YyBhdCB0aGUgc2FtZSB0aW1lLg0KPj4NCj4+IFRoYW5rcw0KPj4gd2VpZ3VvDQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiC3orz+yMs6IERpbm8gRmFyaW5h Y2NpIFtmYXJpbmFjY2lAZ21haWwuY29tXQ0KPj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4yNUgMjI6 MTcNCj4+IMrVvP7IyzogSGFvd2VpZ3VvDQo+PiCzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0 Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQo+PiDW98ziOiBSZTog W252bzNdIENvbW1lbnRzIG9uDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1x dWlubi12eGxhbi1ncGUtMDMNCj4+DQo+Pj4gSGkgRGlubywNCj4+PiBTb3JyeSwgaSBtaXN1bmRl cnN0b29kIHlvdS4gSSB0aGluayBWWExBTi1HUEUgY2FuIGRlZmluZSBhIG5ldyBVRFAgcG9ydA0K Pj4+IGFuZCBhIG5ldyBkYXRhIGZvcm1hdCwgUCBiaXQNCj4+DQo+PiBObyB3b3JyaWVzLg0KPj4N Cj4+PiBpbiBWWExBTi1HUEUgc2VlbXMgdG8gaGF2ZSBubyBhbnkgdmFsdWUuIEFzIGZvciBiYXNp YyBpbnRlci1zdWJuZXQgbGF5ZXINCj4+PiAzIGNvbW11bmljYXRpb24gYW5kIGludHJhLXN1Ym5l dCBsYXllciAyIGNvbW11bmljYXRpb24gYmV0d2VlbiBOVkVzLA0KPj4+IGN1cnJlbnQgTlZHUkUs IFZYTEFOIGFuZCBMSVNQIGhhdmUgYWxyZWFkeSBzdXBwb3J0ZWQsDQo+Pg0KPj4gVlhMQU4gc3Vw cG9ydHMgTDIgb3ZlcmxheXMgc2luY2UgaXRzIGdvYWwgaXMgdG8gZXh0ZW5kIHN1Ym5ldHMuIExJ U1ANCj4+IHN1cHBvcnRzIEwzIG92ZXJsYXlzIHNvIGl0IGFzc3VtZXMgc3VibmV0cyBhcmUgbG9j YWwgKHRvIHRoZSB4VFIpIGp1c3QNCj4+IGxpa2UgaW4gYSByb3V0ZWQgbmV0d29yay4gTlZHUkUg Y2FuIGJlIGEgY29tYm8uDQo+Pg0KPj4+IE5WR1JFLFZYTEFOLExJU1AgYW5kIFZYTEFOLUdQRSBj YW4gYmUgaHlicmlkIHVzZWQgdG8gZm9ybSBhIE5WTzMgbmV0d29yaw0KPj4+IGlmIG9ubHkgYmFz aWMgbGF5ZXIgMyBhbmQNCj4+DQo+PiBUaGVyZSBpcyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBl bmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2ggaXMgY2FsbGVkDQo+PiBWWExBTi1HUEUpIHNvIGl0 IGNhbiBzdXBwb3J0LCBtb3N0IGltcG9ydGFudGx5IE5TSC4gVGhhdCBjaGFuZ2UgYWxzbyBnaXZl cw0KPj4gVlhMQU4gdG8gc3VwcG9ydCBlbmNhcHN1bGF0aW5nIGxheWVyLTIgSVB2NCBhbmQgSVB2 Niwgd2hpY2ggaXMgZHVwbGljYXRlDQo+PiBmdW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUg aGVhZGVycyBhcmUgc28gc2ltaWxhciwgaXQgcmVhbGx5IGRvZW5zJ3QNCj4+IG1hdHRlci4NCj4+ DQo+PiBIb3dldmVyLCB0aGUgUC1iaXQgaXMgbm90IG5lZWRlZCBmb3IgYW55dGhpbmcgbmV3IGlu IExJU1AgYW5kIHRoZSBPQU0tYml0DQo+PiBpcyBub3QgbmVlZGVkIGluIExJU1Agc2luY2UgTElT UCBoYXMgZGlmZmVyZW50IFVEUCBwb3J0IG51bWJlciAoNDM0MikgZm9yDQo+PiBjb250cm9sLXBh Y2tldHMuIFZYTEFOIGRvZXMgbm90IGhhdmUgYSB3ZWxsIGRlZmluZWQgY29udHJvbCBwcm90b2Nv bCBzbw0KPj4gdGhlIGRhdGEtcGxhbmUgaGFzIHRvIGVzY2FwZSBvdXQgY29udHJvbC1wbGFuZSBw YWtjZXRzIHdoZXJlIHRoZSBmaXJzdCBvbmUNCj4+IGlzIHRoaXMgbmV3IE9BTSBtZXNzYWdlLg0K Pj4NCj4+PiBsYXllciAyIGZvcndhcmRpbmcgcHJvY2VzcyBleGlzdHMuIEFzIGZvciBzb21lIGV4 dHJhIGZ1bmN0aW9ucyBvZiBPQU0sDQo+Pj4gc2VydmljZSBjaGFpbmluZyxhbmQgZXRjLCAgb25s eSBWWExBTi1HUEUgY2FuIHN1cHBvcnQsIHB1cmUgVlhMQU4tR1BFDQo+Pj4gbmV0d29yayBzaG91 bGQgYmUgdXNlZCBpbiB0aGVzZSBjYXNlcy4NCj4+PiBUaGFua3MNCj4+PiB3ZWlndW8NCj4+DQo+ PiBSaWdodCwgYWdyZWUuDQo+Pg0KPj4gRGlubw0KPj4NCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ILeivP7IyzogRGlubyBGYXJpbmFj Y2kgW2ZhcmluYWNjaUBnbWFpbC5jb21dDQo+Pj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4yNUgMjE6 MTUNCj4+PiDK1bz+yMs6IEhhb3dlaWd1bw0KPj4+ILOty806IFRvbSBIZXJiZXJ0OyBEYXZpZCBN ZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3QNCj4+PiDW98ziOiBS ZTogtPC4tDogW252bzNdIENvbW1lbnRzIG9uDQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQo+Pj4NCj4+Pj4gT24gSnVsIDI4LCAyMDE0LCBh dCA3OjI0IEFNLCBIYW93ZWlndW8gPGhhb3dlaWd1b0BodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4N Cj4+Pj4gQWJvdXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaSBhbHNvIGFncmVlIHdpdGggRGlu by4gVlhMQU4tR1BFIHNob3VsZA0KPj4+PiBmb2N1cyBvbiAgdGhlIFZYTEFOLUdQRSBoZWFkZXIg YW5kIHJlcXVpcmVzIHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUA0KPj4+PiBwb3J0LCB0aGUg ZGF0YSBmb3JtYXQgZG9uJ3QgbmVlZCBjb25zaWRlciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdp dGgNCj4+Pj4gVlhMQU4gaGVhZGVyLiBJDQo+Pj4NCj4+PiBJIHdhbnQgdG8gbWFrZSBpdCBjbGVh ciB0aGF0IHN1cHBvcnRpbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyB2ZXJ5DQo+Pj4gaW1w b3J0YW50IHNpbmNlIFZYTEFOLXBvcnQtNDc4OSBpcyBzdXBwb3J0ZWQgaW4gdmFyaW91cyBjaGlw cyBhbHJlYWR5Lg0KPj4+DQo+Pj4gRGlubw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBudm8zIG1haWxpbmcgbGlzdA0KPiBudm8zQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw== From nobody Wed Jul 30 04:57:30 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E4A1B278F; Wed, 30 Jul 2014 04:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 uOz3g2_ftzUf; Wed, 30 Jul 2014 04:57:28 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483851A0378; Wed, 30 Jul 2014 04:57:28 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so1345073pdj.12 for ; Wed, 30 Jul 2014 04:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wovimTiHtBZilX1NHNPfw7XevngOp32BCbUQNhW8hxU=; b=KEafjTEJFTcn8SLw8kSjoqTBzPLZgp9VAxnIzm59yDd6N09tUITT8Y642GsuySyPy5 JozP0dwnGubrmjREpAAakSRbnKJ/qnhP2C6+OIQ0aTWEZL+zGkK6tsp/4RiavqANG/Jp 14cvJzyqpuAvaiRGyKFjVLYhRUg5DDxFiRAIVZ7icncyHsbv+omfsrOMOSObAwer7uRu 1sMCJpih/pUcEeCVClDFLWWs6v8Mn9l24K8dducyi/gnLNQ3ZGu96DV359Lo5qLTLxLl 4UBS/ZiyvDSwuC44ofjzD1kD0a0HSkixZN9sMw4Gyu3nJHflG9yo3krydSH29OhNH6nj xzNw== X-Received: by 10.70.60.226 with SMTP id k2mr4024217pdr.130.1406721447940; Wed, 30 Jul 2014 04:57:27 -0700 (PDT) Received: from [192.168.1.34] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id d3sm3176732pdi.49.2014.07.30.04.57.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 04:57:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 30 Jul 2014 04:57:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> To: Haoweiguo Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/TwI9dWi1j01C1w2peSY8aGqtPSc Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBDb21tZW50cyBvbiBodHRwOi8v?= =?utf-8?q?tools=2Eietf=2Eorg/html/draft-quinn-vxlan-gpe-03?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 11:57:30 -0000 A minor correction, LISP does have a unified encapsulation where the packet d= emux function, that has been defined for a few years, is done with UDP ports= . As for VXLAN, the packet demux, has been recently introduced, is done with= the P-bit.=20 Dino > On Jul 29, 2014, at 8:15 PM, Haoweiguo wrote: >=20 > Hi Dino, > VXLAN can use a unified encapsulation to realize both intra-subnet layer 2= traffic forwarding and inter-subnet layer 3 traffic forwarding at the same t= ime, inner destination MAC is used to differenciate layer 2 traffic from lay= er 3 traffic.=20 > LISP uses two different encapsulations for intra-subnet layer 2 traffic fo= rwarding and inter-subnet layer 3 traffic forwarding, UDP port is used to di= fferenciate layer 2 traffic from layer 3 traffic. > =46rom theoretical perspective, both the two solutions are applicable. =46rom= commercial use perspective, the former(unified encap for both layer 2 and l= ayer 3) seems to be more popular currently. > Thanks > weiguo > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8829=E6=97=A5 2= 0:18 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo > =E6=8A=84=E9=80=81: David Melman; nvo3@ietf.org; LISP mailing list list; T= om Herbert > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [nvo3] Comments on http://tool= s.ietf.org/html/draft-quinn-vxlan-gpe-03 >=20 > I understand what you are saying but it comes down to what the encapsulato= r is encapsulating. If the packet it is encapsulating is an L2 frame then th= e encapsulator is supporting a layer-2 overlay service. Otherwise it is a a l= ayer-3 overlay service. >=20 > If the dest MAC Is to the encapsulator that MAC header is stripped before a= layer-3 forwarding decision is made. Then, at which time the packet is forw= arded natively or encapsulated. >=20 > If the dest MAC is not the encapsulator's address, then the MAC header sta= ys with the packet/frame and then encapsulated. >=20 > The former is a layer-3 overlay and the latter is a layer-2 overlay where b= oth can be supported at the same time in one encapsulator device. >=20 > The former is LISP encapsulation and the latter is VXLAN encapsulation. >=20 > With VXLAN-GPE both cases can be supported (and most importantly with a si= ngle unified control-plane). >=20 > So I believe VXLAN-GPE could be useful yet redundant but LISP requires no c= hanges (if LISP supports L2 which is documented in draft-smith-lisp-layer-2= using a different port number). >=20 > Dino >=20 >> On Jul 29, 2014, at 3:58 AM, Haoweiguo wrote: >>=20 >> Hi Dino, >> Thanks for your detail comments. As for current VXLAN encapsulation, pls= see my comments inline with [weiguo] below. >>=20 >> There is motivation to extend an encapsulation header (which is called VX= LAN-GPE) so it can support, most importantly NSH. That change also gives VXL= AN to support encapsulating layer-2 IPv4 and IPv6, which is duplicate functi= onality of LISP. But the headers are so similar, it really doens't matter. >>=20 >> [weiguo]: Yes, an new encapsulation header should be extended to support N= SH. But as for IPv4 and IPv6, i think current VXLAN already supported. For t= he layer 3 inter-subnet traffic from NVE1 to NVE2, inner destination MAC is t= he gateway interface MAC at NVE2. For the layer 2 intra-subnet traffic from= NVE1 to NVE2, inner destination MAC is the destination TS's MAC. When NVE2= receives VXLAN encapsulated traffic from NVE1, inner destination MAC can be= used to differentiate layer 2 traffic from layer 3 traffic. VXLAN distribut= ed layer 3 gateway can be realized through the mechanism, NVE can forward bo= th intra-subnet layer 2 traffic and inter-subnet layer 3 traffic at the same= time. >>=20 >> Thanks >> weiguo >> ________________________________________ >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8828=E6=97=A5 2= 2:17 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo >> =E6=8A=84=E9=80=81: David Melman; nvo3@ietf.org; LISP mailing list list; T= om Herbert >> =E4=B8=BB=E9=A2=98: Re: [nvo3] Comments on http://tools.ietf.org/html/dra= ft-quinn-vxlan-gpe-03 >>=20 >>> Hi Dino, >>> Sorry, i misunderstood you. I think VXLAN-GPE can define a new UDP port a= nd a new data format, P bit >>=20 >> No worries. >>=20 >>> in VXLAN-GPE seems to have no any value. As for basic inter-subnet layer= 3 communication and intra-subnet layer 2 communication between NVEs, curren= t NVGRE, VXLAN and LISP have already supported, >>=20 >> VXLAN supports L2 overlays since its goal is to extend subnets. LISP supp= orts L3 overlays so it assumes subnets are local (to the xTR) just like in a= routed network. NVGRE can be a combo. >>=20 >>> NVGRE,VXLAN,LISP and VXLAN-GPE can be hybrid used to form a NVO3 network= if only basic layer 3 and >>=20 >> There is motivation to extend an encapsulation header (which is called VX= LAN-GPE) so it can support, most importantly NSH. That change also gives VXL= AN to support encapsulating layer-2 IPv4 and IPv6, which is duplicate functi= onality of LISP. But the headers are so similar, it really doens't matter. >>=20 >> However, the P-bit is not needed for anything new in LISP and the OAM-bit= is not needed in LISP since LISP has different UDP port number (4342) for c= ontrol-packets. VXLAN does not have a well defined control protocol so the d= ata-plane has to escape out control-plane pakcets where the first one is thi= s new OAM message. >>=20 >>> layer 2 forwarding process exists. As for some extra functions of OAM, s= ervice chaining,and etc, only VXLAN-GPE can support, pure VXLAN-GPE network= should be used in these cases. >>> Thanks >>> weiguo >>=20 >> Right, agree. >>=20 >> Dino >>=20 >>>=20 >>>=20 >>> ________________________________________ >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8828=E6=97=A5= 21:15 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo >>> =E6=8A=84=E9=80=81: Tom Herbert; David Melman; nvo3@ietf.org; LISP maili= ng list list >>> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [nvo3] Comments on http://to= ols.ietf.org/html/draft-quinn-vxlan-gpe-03 >>>=20 >>>> On Jul 28, 2014, at 7:24 AM, Haoweiguo wrote: >>>>=20 >>>> About backward compatibility, i also agree with Dino. VXLAN-GPE should f= ocus on the VXLAN-GPE header and requires the assignment of a new UDP port,= the data format don't need consider backward compatibility with VXLAN heade= r. I >>>=20 >>> I want to make it clear that supporting backward compatibility is very i= mportant since VXLAN-port-4789 is supported in various chips already. >>>=20 >>> Dino From nobody Wed Jul 30 05:00:54 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148D41B278F; Wed, 30 Jul 2014 05:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 7Wk-2GGBPu0V; Wed, 30 Jul 2014 05:00:42 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC551A0378; Wed, 30 Jul 2014 05:00:42 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id z10so1340438pdj.16 for ; Wed, 30 Jul 2014 05:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IstDw4WBae0Dhkta/1pLnXkw0VdMyGDaXZYCYSAi5BI=; b=m2oa44l6hk2Nl7MbeDd+57cd8pk1dQ7nH1PqJ85wvE3EI+8DIOuFVFCgni50cdYKvZ L/RkkPhrsrnzsCE9uEp+Wv3/x0/he0zZn4bCfRyM+MtXR+9vBL5w8WfQey5UGYZxgLu9 7jRgZT3JyKnYTimDLifhhRPdo4BxwQg+rQOJLVtMVkzAMUOEncRqdbYmn4sr8Dp50CDZ UUBXuiGj6pTR0XjiVUXt5u+ViFo1jN/oly1UkINIqgmT8sXIc4XyiHAzblcV2iDlv9Po qZj2vN1dl3pWIyGeTqc0XjGrPci7vdH6bO29knNA7pE2yqW927UUMOqU+p2Agkvh0QBa DtIA== X-Received: by 10.66.163.226 with SMTP id yl2mr3891472pab.73.1406721642057; Wed, 30 Jul 2014 05:00:42 -0700 (PDT) Received: from [192.168.1.34] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id z4sm3202999pdb.18.2014.07.30.05.00.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 05:00:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 30 Jul 2014 05:00:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> <20140729234019087723.ceceb885@sniff.de> To: Haoweiguo Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/MuYOuJJv2gwhyik2w1Rvrhkxvvg Cc: Tom Herbert , David Melman , Marc Binderberger , LISP mailing list list , "nvo3@ietf.org" Subject: Re: [nvo3] =?utf-8?b?562U5aSNOiAg562U5aSNOiDnrZTlpI06ICBDb21tZW50cyBv?= =?utf-8?q?n_http=3A//tools=2Eietf=2Eorg/html/draft-quinn-vxlan-gpe-03?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 12:00:48 -0000 > On Jul 30, 2014, at 2:29 AM, Haoweiguo wrote: >=20 > VXLAN-GPE have next protocol field, so it can combine multiple data planes= into one VXLAN-gpe. Currently inner destination MAC can be used to distingu= ish layer 2 and layer 3 traffic at egress NVE. You can do what you say today with VXLAN. You don't need GPE for this. The d= emux is just in the ethertype field if the inner MAC header.=20 Dino=20= From nobody Wed Jul 30 07:20:10 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD671A00BA; Wed, 30 Jul 2014 07:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.999 X-Spam-Level: **** X-Spam-Status: No, score=4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001] autolearn=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 Hk9L795JeHyU; Wed, 30 Jul 2014 07:19:55 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B60AD1A00AB; Wed, 30 Jul 2014 07:19:54 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 80E3E2AA0F; Wed, 30 Jul 2014 14:19:51 +0000 (GMT) Date: Wed, 30 Jul 2014 07:19:55 -0700 From: Marc Binderberger To: Haoweiguo Message-ID: <20140730071955406839.4eeb788e@sniff.de> In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> <20140729234019087723.ceceb885@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/0g6REiHrUVd9jNDH2PJ1Q2MSx5w Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Dino Farinacci , Tom Herbert Subject: Re: [nvo3] =?gb2312?b?tPC4tDogILTwuLQ6ILTwuLQ6IENvbW1lbnRzIG9uIGh0?= =?gb2312?b?dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdw?= =?gb2312?b?ZS0wMw==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:19:57 -0000 SGVsbG8gV2VpZ3VvLA0KDQo+IFZYTEFOLUdQRSBoYXZlIG5leHQgcHJvdG9jb2wgZmllbGQs IHNvIGl0IGNhbiBjb21iaW5lIG11bHRpcGxlIGRhdGEgcGxhbmVzIA0KPiBpbnRvIG9uZSBW WExBTi1ncGUuDQoNCnNvIHlvdSBhcmUgZmluZSB3aXRoIHRoZSBWeExBTi1ncGUgbGF5b3V0 IHRoZW4/IE9rYXksIEkgbWlzdW5kZXJzdG9vZCB0aGlzLg0KDQo+IEN1cnJlbnRseSBpbm5l ciBkZXN0aW5hdGlvbiBNQUMgY2FuIGJlIHVzZWQgdG8gDQo+IGRpc3Rpbmd1aXNoIGxheWVy IDIgYW5kIGxheWVyIDMgdHJhZmZpYyBhdCBlZ3Jlc3MgTlZFLg0KDQphcyBJIHNhaWQgSSBz ZWUgYSBzdWJ0bGUgZGlmZmVyZW5jZSBoZXJlIGFuZCB3b3VsZCBzYXkgVnhMQU4gaXMgZG9p bmcgYSANCmxheWVyLTIgb3BlcmF0aW9uLiBOZXZlcnRoZWxlc3MsIGlmIHlvdXIgZW5jYXBz dWxhdGlvbi9kZWNhcHN1bGF0aW9uIG5ldHdvcmsgDQplbGVtZW50cyB1bmRlcnN0YW5kIHRo aXMgbGF5ZXItMiBhc3BlY3QsIGFyZSBjYXBhYmxlIHRvIGFkZCBFdGhlcm5ldCBoZWFkZXIs IA0KVnhMQU4gc2hpbSBhbmQgb3V0ZXIgSVAgaGVhZGVyIG9udG8gdGhlIGlubmVyIElQIHBh Y2tldCBldGMuLCB0aGVuIHllcywgeW91IA0KY291bGQgdHJhbnNwb3J0IGxheWVyLTMgd2l0 aCBWeExBTi4NCg0KDQpSZWdhcmRzLCBNYXJjDQoNCg0KDQo+IFRoYW5rcw0KPiB3ZWlndW8N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiC3orz+yMs6 IE1hcmMgQmluZGVyYmVyZ2VyIFttYXJjQHNuaWZmLmRlXQ0KPiC3osvNyrG85DogMjAxNMTq N9TCMzDI1SAxNDo0MA0KPiDK1bz+yMs6IEhhb3dlaWd1bw0KPiCzrcvNOiBEaW5vIEZhcmlu YWNjaTsgRGF2aWQgTWVsbWFuOyBudm8zQGlldGYub3JnOyBMSVNQIG1haWxpbmcgbGlzdCBs aXN0OyANCj4gVG9tIEhlcmJlcnQNCj4g1vfM4jogUmU6IFtudm8zXSC08Li0OiC08Li0OiAg Q29tbWVudHMgb24gDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5u LXZ4bGFuLWdwZS0wMw0KPiANCj4gSGVsbG8gV2VpZ3VvLA0KPiANCj4gSSB3b3VsZCBzYXkg dGhlcmUgaXMgYSBkaWZmZXJlbmNlIGlmIHlvdXIgImxheWVyLTMiIHNlcnZpY2UgaXMgYWN0 dWFsbHkgYQ0KPiBsYXllci0yIEV0aGVybmV0IGZyYW1lIHdpdGggdGhlIGRlc3RpbmF0aW9u IE1BQyBvZiB0aGUgZW5jYXBzdWxhdGVkIHBhY2tldA0KPiBiZWluZyBpZGVudGljYWwgd2l0 aCB0aGUgTUFDIG9mIHRoZSBkZWNhcHN1bGF0aW5nIHN5c3RlbSwgY29tcGFyZWQgdG8gYQ0K PiBsYXllci0zIHNlcnZpY2Ugd2hlcmUgeW91ciB3aG9sZSBwcm9jZXNzaW5nIHN0YXlzIHNv bGVseSBpbiB0aGUgbGF5ZXItMywgbm8NCj4gTUFDIGludm9sdmVkLg0KPiANCj4gSWYgSSB3 YW50IHRvIGRlZmluZSBhIGxheWVyLTMgZW5jYXBzdWxhdGlvbiAobGlrZSBMSVNQLCBsaWtl IHRoZSBwcm9wb3NlZA0KPiBWeExBTi1ncGUgd2l0aCBJUHY0L3Y2IGFzIHByb3RvY29sKSB0 aGVuIGhhdmluZyBhbnkgbGF5ZXItMiBpbiB0aGUgcHJvY2Vzcw0KPiBzZWVtcyBhIGJpdCAi b2RkIi4gV29yc2UsIHRoZSBpbnZvbHZlZCBzeXN0ZW1zIG1heSBub3QgaGF2ZSB0aGlzIGxh eWVyLTINCj4gbG9naWMuIExJU1AgZm9yIGV4YW1wbGUgaXMgb2Z0ZW4gdXNlZCBpbiB0aGUg V0FOLCBldmVuIHdoZW4gc29tZQ0KPiBlbmNhcHN1bGF0b3IvZGVjYXBzdWxhdG9yIGFyZSBE QyBzd2l0Y2hlcy4gU29tZSBvZiB0aGVzZSBXQU4gc3lzdGVtcyBtYXkgYmUNCj4gcHVyZSBJ UHY0L3Y2IHJvdXRlcnMuDQo+IA0KPiANCj4gSW4gb3RoZXIgd29yZHM6IGhhdmluZyBib3Ro IGEgbGF5ZXItMiAoVnhMQU4pIGFuZCBhIGxheWVyLTMgKExJU1ApDQo+IGVuY2Fwc3VsYXRp b24gbWFrZXMgZ29vZCBzZW5zZS4gVGhlIHF1ZXN0aW9uIGlzOiBzaGFsbCB3ZSBrZWVwIGl0 IHNlcGFyYXRlZA0KPiBhcyBpdCBpcyB0b2RheSBhcyAiTElTUCIgYW5kICJWeExBTiIgb3Ig Y29tYmluZSB0aGUgKGV4cGVuc2l2ZSkgbXVsdGlwbGUgDQo+IGRhdGENCj4gcGxhbmVzIGlu dG8gb25lIFZ4TEFOLWdwZS4NCj4gDQo+IA0KPiBSZWdhcmRzLCBNYXJjDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gT24gV2VkLCAzMCBKdWwgMjAxNCAwMzoxNToxOSArMDAwMCwgSGFvd2Vp Z3VvIHdyb3RlOg0KPj4gSGkgRGlubywNCj4+IFZYTEFOIGNhbiB1c2UgYSB1bmlmaWVkIGVu Y2Fwc3VsYXRpb24gdG8gcmVhbGl6ZSBib3RoIGludHJhLXN1Ym5ldCBsYXllciAyDQo+PiB0 cmFmZmljIGZvcndhcmRpbmcgYW5kIGludGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgZm9y d2FyZGluZyBhdCB0aGUgc2FtZQ0KPj4gdGltZSwgaW5uZXIgZGVzdGluYXRpb24gTUFDIGlz IHVzZWQgdG8gZGlmZmVyZW5jaWF0ZSBsYXllciAyIHRyYWZmaWMgZnJvbQ0KPj4gbGF5ZXIg MyB0cmFmZmljLg0KPj4gTElTUCB1c2VzIHR3byBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbnMg Zm9yIGludHJhLXN1Ym5ldCBsYXllciAyIHRyYWZmaWMNCj4+IGZvcndhcmRpbmcgYW5kIGlu dGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgZm9yd2FyZGluZywgVURQIHBvcnQgaXMgdXNl ZCB0bw0KPj4gZGlmZmVyZW5jaWF0ZSBsYXllciAyIHRyYWZmaWMgZnJvbSBsYXllciAzIHRy YWZmaWMuDQo+PiBGcm9tIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZlLCAgYm90aCB0aGUgdHdv IHNvbHV0aW9ucyBhcmUgYXBwbGljYWJsZS4gRnJvbQ0KPj4gY29tbWVyY2lhbCB1c2UgcGVy c3BlY3RpdmUsIHRoZSBmb3JtZXIodW5pZmllZCBlbmNhcCBmb3IgYm90aCBsYXllciAyIGFu ZA0KPj4gbGF5ZXIgMykgc2VlbXMgdG8gYmUgbW9yZSBwb3B1bGFyIGN1cnJlbnRseS4NCj4+ IFRoYW5rcw0KPj4gd2VpZ3VvDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiC3orz+yMs6IERpbm8gRmFyaW5hY2NpIFtmYXJpbmFjY2lAZ21haWwu Y29tXQ0KPj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI5yNUgMjA6MTgNCj4+IMrVvP7IyzogSGFv d2VpZ3VvDQo+PiCzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFp bGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQo+PiDW98ziOiBSZTogtPC4tDogW252bzNd IENvbW1lbnRzIG9uDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlu bi12eGxhbi1ncGUtMDMNCj4+IA0KPj4gSSB1bmRlcnN0YW5kIHdoYXQgeW91IGFyZSBzYXlp bmcgYnV0IGl0IGNvbWVzIGRvd24gdG8gd2hhdCB0aGUgZW5jYXBzdWxhdG9yDQo+PiBpcyBl bmNhcHN1bGF0aW5nLiBJZiB0aGUgcGFja2V0IGl0IGlzIGVuY2Fwc3VsYXRpbmcgaXMgYW4g TDIgZnJhbWUgdGhlbiB0aGUNCj4+IGVuY2Fwc3VsYXRvciBpcyBzdXBwb3J0aW5nIGEgbGF5 ZXItMiBvdmVybGF5IHNlcnZpY2UuIE90aGVyd2lzZSBpdCBpcyBhIGENCj4+IGxheWVyLTMg b3ZlcmxheSBzZXJ2aWNlLg0KPj4gDQo+PiBJZiB0aGUgZGVzdCBNQUMgSXMgdG8gdGhlIGVu Y2Fwc3VsYXRvciB0aGF0IE1BQyBoZWFkZXIgaXMgc3RyaXBwZWQgYmVmb3JlIGENCj4+IGxh eWVyLTMgZm9yd2FyZGluZyBkZWNpc2lvbiBpcyBtYWRlLiBUaGVuLCBhdCB3aGljaCB0aW1l IHRoZSBwYWNrZXQgaXMNCj4+IGZvcndhcmRlZCBuYXRpdmVseSBvciBlbmNhcHN1bGF0ZWQu DQo+PiANCj4+IElmIHRoZSBkZXN0IE1BQyBpcyBub3QgdGhlIGVuY2Fwc3VsYXRvcidzIGFk ZHJlc3MsIHRoZW4gdGhlIE1BQyBoZWFkZXINCj4+IHN0YXlzIHdpdGggdGhlIHBhY2tldC9m cmFtZSBhbmQgdGhlbiBlbmNhcHN1bGF0ZWQuDQo+PiANCj4+IFRoZSBmb3JtZXIgaXMgYSBs YXllci0zIG92ZXJsYXkgYW5kIHRoZSBsYXR0ZXIgaXMgYSBsYXllci0yIG92ZXJsYXkgd2hl cmUNCj4+IGJvdGggY2FuIGJlIHN1cHBvcnRlZCBhdCB0aGUgc2FtZSB0aW1lIGluIG9uZSBl bmNhcHN1bGF0b3IgZGV2aWNlLg0KPj4gDQo+PiBUaGUgZm9ybWVyIGlzIExJU1AgZW5jYXBz dWxhdGlvbiBhbmQgdGhlIGxhdHRlciBpcyBWWExBTiBlbmNhcHN1bGF0aW9uLg0KPj4gDQo+ PiBXaXRoIFZYTEFOLUdQRSBib3RoIGNhc2VzIGNhbiBiZSBzdXBwb3J0ZWQgKGFuZCBtb3N0 IGltcG9ydGFudGx5IHdpdGggYQ0KPj4gc2luZ2xlIHVuaWZpZWQgY29udHJvbC1wbGFuZSku DQo+PiANCj4+IFNvIEkgYmVsaWV2ZSBWWExBTi1HUEUgY291bGQgYmUgdXNlZnVsIHlldCBy ZWR1bmRhbnQgYnV0IExJU1AgcmVxdWlyZXMgbm8NCj4+IGNoYW5nZXMgKGlmIExJU1Agc3Vw cG9ydHMgIEwyIHdoaWNoIGlzIGRvY3VtZW50ZWQgaW4NCj4+IGRyYWZ0LXNtaXRoLWxpc3At bGF5ZXItMiB1c2luZyBhIGRpZmZlcmVudCBwb3J0IG51bWJlcikuDQo+PiANCj4+IERpbm8N Cj4+IA0KPj4+IE9uIEp1bCAyOSwgMjAxNCwgYXQgMzo1OCBBTSwgSGFvd2VpZ3VvIDxoYW93 ZWlndW9AaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgRGlubywNCj4+PiBUaGFu a3MgZm9yIHlvdXIgZGV0YWlsIGNvbW1lbnRzLiAgQXMgZm9yIGN1cnJlbnQgVlhMQU4gZW5j YXBzdWxhdGlvbiwgcGxzDQo+Pj4gc2VlIG15IGNvbW1lbnRzIGlubGluZSB3aXRoIFt3ZWln dW9dIGJlbG93Lg0KPj4+IA0KPj4+IFRoZXJlIGlzIG1vdGl2YXRpb24gdG8gZXh0ZW5kIGFu IGVuY2Fwc3VsYXRpb24gaGVhZGVyICh3aGljaCBpcyBjYWxsZWQNCj4+PiBWWExBTi1HUEUp IHNvIGl0IGNhbiBzdXBwb3J0LCBtb3N0IGltcG9ydGFudGx5IE5TSC4gVGhhdCBjaGFuZ2Ug YWxzbyBnaXZlcw0KPj4+IFZYTEFOIHRvIHN1cHBvcnQgZW5jYXBzdWxhdGluZyBsYXllci0y IElQdjQgYW5kIElQdjYsIHdoaWNoIGlzIGR1cGxpY2F0ZQ0KPj4+IGZ1bmN0aW9uYWxpdHkg b2YgTElTUC4gQnV0IHRoZSBoZWFkZXJzIGFyZSBzbyBzaW1pbGFyLCBpdCByZWFsbHkgZG9l bnMndA0KPj4+IG1hdHRlci4NCj4+PiANCj4+PiBbd2VpZ3VvXTogWWVzLCBhbiBuZXcgZW5j YXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQNCj4+PiBO U0guIEJ1dCBhcyBmb3IgSVB2NCBhbmQgSVB2NiwgaSB0aGluayBjdXJyZW50IFZYTEFOIGFs cmVhZHkgc3VwcG9ydGVkLg0KPj4+IEZvciB0aGUgbGF5ZXIgMyBpbnRlci1zdWJuZXQgdHJh ZmZpYyBmcm9tIE5WRTEgdG8gTlZFMiwgaW5uZXIgZGVzdGluYXRpb24NCj4+PiBNQUMgaXMg dGhlIGdhdGV3YXkgaW50ZXJmYWNlIE1BQyBhdCBOVkUyLiAgRm9yIHRoZSBsYXllciAyIGlu dHJhLXN1Ym5ldA0KPj4+IHRyYWZmaWMgZnJvbSBOVkUxIHRvIE5WRTIsICBpbm5lciBkZXN0 aW5hdGlvbiBNQUMgaXMgdGhlIGRlc3RpbmF0aW9uIFRTJ3MNCj4+PiBNQUMuIFdoZW4gTlZF MiByZWNlaXZlcyBWWExBTiBlbmNhcHN1bGF0ZWQgdHJhZmZpYyBmcm9tIE5WRTEsIGlubmVy DQo+Pj4gZGVzdGluYXRpb24gTUFDIGNhbiBiZSB1c2VkIHRvIGRpZmZlcmVudGlhdGUgbGF5 ZXIgMiB0cmFmZmljIGZyb20gbGF5ZXIgMw0KPj4+IHRyYWZmaWMuIFZYTEFOIGRpc3RyaWJ1 dGVkIGxheWVyIDMgZ2F0ZXdheSBjYW4gYmUgcmVhbGl6ZWQgdGhyb3VnaCB0aGUNCj4+PiBt ZWNoYW5pc20sIE5WRSBjYW4gZm9yd2FyZCBib3RoIGludHJhLXN1Ym5ldCBsYXllciAyIHRy YWZmaWMgYW5kDQo+Pj4gaW50ZXItc3VibmV0IGxheWVyIDMgdHJhZmZpYyBhdCB0aGUgc2Ft ZSB0aW1lLg0KPj4+IA0KPj4+IFRoYW5rcw0KPj4+IHdlaWd1bw0KPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiC3orz+yMs6IERpbm8gRmFyaW5h Y2NpIFtmYXJpbmFjY2lAZ21haWwuY29tXQ0KPj4+ILeiy83KsbzkOiAyMDE0xOo31MIyOMjV IDIyOjE3DQo+Pj4gytW8/sjLOiBIYW93ZWlndW8NCj4+PiCzrcvNOiBEYXZpZCBNZWxtYW47 IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQo+ Pj4g1vfM4jogUmU6IFtudm8zXSBDb21tZW50cyBvbg0KPj4+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KPj4+IA0KPj4+PiBIaSBEaW5v LA0KPj4+PiBTb3JyeSwgaSBtaXN1bmRlcnN0b29kIHlvdS4gSSB0aGluayBWWExBTi1HUEUg Y2FuIGRlZmluZSBhIG5ldyBVRFAgcG9ydA0KPj4+PiBhbmQgYSBuZXcgZGF0YSBmb3JtYXQs IFAgYml0DQo+Pj4gDQo+Pj4gTm8gd29ycmllcy4NCj4+PiANCj4+Pj4gaW4gVlhMQU4tR1BF IHNlZW1zIHRvIGhhdmUgbm8gYW55IHZhbHVlLiBBcyBmb3IgYmFzaWMgaW50ZXItc3VibmV0 IGxheWVyDQo+Pj4+IDMgY29tbXVuaWNhdGlvbiBhbmQgaW50cmEtc3VibmV0IGxheWVyIDIg Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIE5WRXMsDQo+Pj4+IGN1cnJlbnQgTlZHUkUsIFZYTEFO IGFuZCBMSVNQIGhhdmUgYWxyZWFkeSBzdXBwb3J0ZWQsDQo+Pj4gDQo+Pj4gVlhMQU4gc3Vw cG9ydHMgTDIgb3ZlcmxheXMgc2luY2UgaXRzIGdvYWwgaXMgdG8gZXh0ZW5kIHN1Ym5ldHMu IExJU1ANCj4+PiBzdXBwb3J0cyBMMyBvdmVybGF5cyBzbyBpdCBhc3N1bWVzIHN1Ym5ldHMg YXJlIGxvY2FsICh0byB0aGUgeFRSKSBqdXN0DQo+Pj4gbGlrZSBpbiBhIHJvdXRlZCBuZXR3 b3JrLiBOVkdSRSBjYW4gYmUgYSBjb21iby4NCj4+PiANCj4+Pj4gTlZHUkUsVlhMQU4sTElT UCBhbmQgVlhMQU4tR1BFIGNhbiBiZSBoeWJyaWQgdXNlZCB0byBmb3JtIGEgTlZPMyBuZXR3 b3JrDQo+Pj4+IGlmIG9ubHkgYmFzaWMgbGF5ZXIgMyBhbmQNCj4+PiANCj4+PiBUaGVyZSBp cyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBlbmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2gg aXMgY2FsbGVkDQo+Pj4gVlhMQU4tR1BFKSBzbyBpdCBjYW4gc3VwcG9ydCwgbW9zdCBpbXBv cnRhbnRseSBOU0guIFRoYXQgY2hhbmdlIGFsc28gZ2l2ZXMNCj4+PiBWWExBTiB0byBzdXBw b3J0IGVuY2Fwc3VsYXRpbmcgbGF5ZXItMiBJUHY0IGFuZCBJUHY2LCB3aGljaCBpcyBkdXBs aWNhdGUNCj4+PiBmdW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUg c28gc2ltaWxhciwgaXQgcmVhbGx5IGRvZW5zJ3QNCj4+PiBtYXR0ZXIuDQo+Pj4gDQo+Pj4g SG93ZXZlciwgdGhlIFAtYml0IGlzIG5vdCBuZWVkZWQgZm9yIGFueXRoaW5nIG5ldyBpbiBM SVNQIGFuZCB0aGUgT0FNLWJpdA0KPj4+IGlzIG5vdCBuZWVkZWQgaW4gTElTUCBzaW5jZSBM SVNQIGhhcyBkaWZmZXJlbnQgVURQIHBvcnQgbnVtYmVyICg0MzQyKSBmb3INCj4+PiBjb250 cm9sLXBhY2tldHMuIFZYTEFOIGRvZXMgbm90IGhhdmUgYSB3ZWxsIGRlZmluZWQgY29udHJv bCBwcm90b2NvbCBzbw0KPj4+IHRoZSBkYXRhLXBsYW5lIGhhcyB0byBlc2NhcGUgb3V0IGNv bnRyb2wtcGxhbmUgcGFrY2V0cyB3aGVyZSB0aGUgZmlyc3Qgb25lDQo+Pj4gaXMgdGhpcyBu ZXcgT0FNIG1lc3NhZ2UuDQo+Pj4gDQo+Pj4+IGxheWVyIDIgZm9yd2FyZGluZyBwcm9jZXNz IGV4aXN0cy4gQXMgZm9yIHNvbWUgZXh0cmEgZnVuY3Rpb25zIG9mIE9BTSwNCj4+Pj4gc2Vy dmljZSBjaGFpbmluZyxhbmQgZXRjLCAgb25seSBWWExBTi1HUEUgY2FuIHN1cHBvcnQsIHB1 cmUgVlhMQU4tR1BFDQo+Pj4+IG5ldHdvcmsgc2hvdWxkIGJlIHVzZWQgaW4gdGhlc2UgY2Fz ZXMuDQo+Pj4+IFRoYW5rcw0KPj4+PiB3ZWlndW8NCj4+PiANCj4+PiBSaWdodCwgYWdyZWUu DQo+Pj4gDQo+Pj4gRGlubw0KPj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gt6K8/sjLOiBEaW5vIEZhcmlu YWNjaSBbZmFyaW5hY2NpQGdtYWlsLmNvbV0NCj4+Pj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4 yNUgMjE6MTUNCj4+Pj4gytW8/sjLOiBIYW93ZWlndW8NCj4+Pj4gs63LzTogVG9tIEhlcmJl cnQ7IERhdmlkIE1lbG1hbjsgbnZvM0BpZXRmLm9yZzsgTElTUCBtYWlsaW5nIGxpc3QgbGlz dA0KPj4+PiDW98ziOiBSZTogtPC4tDogW252bzNdIENvbW1lbnRzIG9uDQo+Pj4+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KPj4+PiAN Cj4+Pj4+IE9uIEp1bCAyOCwgMjAxNCwgYXQgNzoyNCBBTSwgSGFvd2VpZ3VvIDxoYW93ZWln dW9AaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IEFib3V0IGJhY2t3YXJkIGNv bXBhdGliaWxpdHksIGkgYWxzbyBhZ3JlZSB3aXRoIERpbm8uIFZYTEFOLUdQRSBzaG91bGQN Cj4+Pj4+IGZvY3VzIG9uICB0aGUgVlhMQU4tR1BFIGhlYWRlciBhbmQgcmVxdWlyZXMgdGhl IGFzc2lnbm1lbnQgb2YgYSBuZXcgVURQDQo+Pj4+PiBwb3J0LCB0aGUgZGF0YSBmb3JtYXQg ZG9uJ3QgbmVlZCBjb25zaWRlciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGgNCj4+Pj4+ IFZYTEFOIGhlYWRlci4gSQ0KPj4+PiANCj4+Pj4gSSB3YW50IHRvIG1ha2UgaXQgY2xlYXIg dGhhdCBzdXBwb3J0aW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXMgdmVyeQ0KPj4+PiBp bXBvcnRhbnQgc2luY2UgVlhMQU4tcG9ydC00Nzg5IGlzIHN1cHBvcnRlZCBpbiB2YXJpb3Vz IGNoaXBzIGFscmVhZHkuDQo+Pj4+IA0KPj4+PiBEaW5vDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbnZvMyBtYWlsaW5nIGxpc3QN Cj4+IG52bzNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbnZvMw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBudm8zIG1haWxpbmcgbGlzdA0KPiBudm8zQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw== From nobody Wed Jul 30 14:42:32 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804971A0101; Wed, 30 Jul 2014 14:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 MQhm5QZD5weL; Wed, 30 Jul 2014 14:42:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FA91A00E5; Wed, 30 Jul 2014 14:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2097; q=dns/txt; s=iport; t=1406756549; x=1407966149; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uBVp+5Pk6OiRj01bxD7s+Xy4UV/LEHmxf1+mpSJYTR4=; b=i0/1DeDIkaIyO515fDFeLr4uq17xw4orGs4XvOmrIxflmenjplMddjdi 3zl/kJLG7vc5rtG3ZEs2s1K5ooHqwzwyNk4i3fe4QAqbPbEnQxMg2pWj/ Ur0j1/i8d4Eh1g296OKmBd/6Bh8uAJ32UzBLYRMW+VcWjriV+FuOGYaHl M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAMdl2VOtJV2P/2dsb2JhbABZgw5SVwTKZh4Kh0sBgRAWd4QEAQEBAwEBATc0CxACAQgYHhAhBgslAgQBDQWILgMRDbkeDYcJF40fgi0HhEoFmV+CBYFSjFyGJYNJbIFF X-IronPort-AV: E=Sophos;i="5.01,767,1400025600"; d="scan'208";a="343776426" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP; 30 Jul 2014 21:42:28 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6ULgRVf013949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 21:42:27 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 16:42:27 -0500 From: "Larry Kreeger (kreeger)" To: Dino Farinacci , Marc Binderberger Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDUc+I5/u44SU2TO/uEBEAfx5u09aOAgABtLwCAAIjTgIAAzUAAgAAT34CAAAUFgIAABKAAgAIym4A= Date: Wed, 30 Jul 2014 21:42:27 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> In-Reply-To: <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.21.126.25] Content-Type: text/plain; charset="us-ascii" Content-ID: <9587D2A77C18D542A53C7E3AE90A75F1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/px2Pw6nZ8NTeoHt3bUMCTHsYBq4 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 21:42:31 -0000 Hi Dino, On 7/29/14 1:08 AM, "Dino Farinacci" wrote: > > >> On Jul 28, 2014, at 9:52 PM, Marc Binderberger wrote: >>=20 >> Hello Dino, >>=20 >> thanks for this comment - that's an interesting point of view. >>=20 >> Hmm, how do the O (or RA in another draft) and the P bit fit into this > >O-bit in LISP is not needed. I told the LUSP-GPE authors this. Because >OAM-packets like all other control packets go in UDP port 4342 (where >encapsulated packets go in UDP port 4341). I can see the O-bit being useful when you want to use port 4341 to help ensure that OAM packets use the same path through the network as the user data packets. >=20 > >And P-bit is not needed and the authors indicated the main motivation was >to keep consistent with VXLAN so same hardware design could do both. LISP >already has port 8473 for L2 frames. I assume you meant 8472 (assigned to OTV and used by VXLAN implementation pre-IANA assignment). I'm not sure you can technically call this a LISP port. >And NSH is a service protocol and should run above the transport layer so >should have its own port and can address packets anywhere. I think the intent of NSH is to be generic enough to work at different layers. The recent addition of the Metadata Type field in the NSH header allows for it to be used for purposes beyond SFC. It could theoretically be used to essentially extend the header of the layer below it (e.g. VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 bit VNI authentication. - Larry >Just like any other UDP application. If that packet needs to be >encapsulated that is a lower level function. Just like IP packets can go >in an MPLS based LSP. > >> picture? They do mean something about how the packet is handled, don't >>they? > >I won't answer that because those bit introductions into the design are >indeed design bugs IMO. > >Dino >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jul 30 14:46:21 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F641A0087 for ; Wed, 30 Jul 2014 14:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 BP4eaECoi0l4 for ; Wed, 30 Jul 2014 14:46:16 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2121A005D for ; Wed, 30 Jul 2014 14:46:16 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rd18so2320566iec.23 for ; Wed, 30 Jul 2014 14:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OfUct+sRxOMQif9heMFz7ECwVA5kInTTht9URQGyoPI=; b=Zpli9aaHkhRB9RHvyYmhGNWd7bDdrFY01h78NP92aDAjYgy/n1UT2WC/bdDkUB8Ift soC/uWK7DAE5vHoK201LNAZ+/olNCCeldbF+Ut9oE/lO/7blkhzwPEhx6B174+XPYUj5 G4UkHISw8SpV5xsJ0jTGxy+z3NR0jUPsDfHMmRWUMN88CgtzgHF70pckNX+w+l2Rd1Gw vTJqfI4QOeMhUuwFe006zHPw00k4fYLemIyhkBLaU5ttDpMLEA+bdSthkDPneq3YTnll uMXCHGqTFGp1ixHbdYkJRjSD72r7yUlunWX/lV1VmIZuz64edTDEBz60euG2lMHbrStv rOwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OfUct+sRxOMQif9heMFz7ECwVA5kInTTht9URQGyoPI=; b=U++zFALpVKylDLCLgSkkjx4i83WhMGK6jpmsBoLBXd+Q3zQrr8dK6zGJsYgYo5zMV2 fErCOMj7xJJ5IFUR9tcB4wCofByB65vsUPSrC7fFVhK9SfwV5h7Dp3zlgD6hnuH/JArO 5IuNma5KlBhRLKEMwgRFbvx2Nv8A0/hc1BPKHS02lMda/r0jOZ0f/9+XX6OG+KU7Rb7e WUJTMyysiEqGyzeWze7yiU4fK/oXqfhgUVPw/cDWGaAEpHrJKRWVhNEPx0O/qzOxPH7+ 8pg2ri6elldLQ+ZvggLnv1KdqE+q8Zl6dibCVUI5UTdXbLJieYI6CCs71WvFwV/UxK/x cDdA== X-Gm-Message-State: ALoCoQnkNfPhSg2aIQ+y0cB3/HWvnyE/cr4eTvS18EZBrrq5StShvN/Wz24gWmInVfbF55HAfSzS MIME-Version: 1.0 X-Received: by 10.42.252.201 with SMTP id mx9mr9447097icb.78.1406756775563; Wed, 30 Jul 2014 14:46:15 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Wed, 30 Jul 2014 14:46:15 -0700 (PDT) In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> Date: Wed, 30 Jul 2014 14:46:15 -0700 Message-ID: From: Tom Herbert To: "Larry Kreeger (kreeger)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/iHFuenIdFZzo-25Ou29f_B42DDE Cc: David Melman , Marc Binderberger , LISP mailing list list , Dino Farinacci , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 21:46:17 -0000 > I think the intent of NSH is to be generic enough to work at different > layers. The recent addition of the Metadata Type field in the NSH header > allows for it to be used for purposes beyond SFC. It could theoretically > be used to essentially extend the header of the layer below it (e.g. > VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 bit > VNI authentication. > I'd be interested to see exactly what the headers might look like in that case. I've tried to extrapolate from the SFC drafts how that might work but really don't see it... Thanks, Tom > - Larry > >>Just like any other UDP application. If that packet needs to be >>encapsulated that is a lower level function. Just like IP packets can go >>in an MPLS based LSP. >> >>> picture? They do mean something about how the packet is handled, don't >>>they? >> >>I won't answer that because those bit introductions into the design are >>indeed design bugs IMO. >> >>Dino >>_______________________________________________ >>nvo3 mailing list >>nvo3@ietf.org >>https://www.ietf.org/mailman/listinfo/nvo3 > From nobody Wed Jul 30 15:00:45 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FAF1A016C; Wed, 30 Jul 2014 15:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 YzpcGMiH4HOo; Wed, 30 Jul 2014 15:00:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F8A1A0422; Wed, 30 Jul 2014 15:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2165; q=dns/txt; s=iport; t=1406757641; x=1407967241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1XF4xPiqdy1W/oMOSOg52oxx/dlPn/7jRSpRHamPVh0=; b=KXJs/bvB4EIrqbqwNhjcrdfbLWw4ZD0HmyP44JTqV4jiJytl6Hr/McKK ay279H2Iei6UEaV23Eik5ss5MvkNnkiyB5UQa/ypiDoI5omG9b/Xmg0hO LKdHuDodMEMGf3ktosM/TYKYMVfutO4MH745MZNgjcvSGM0LDnS3qTKXr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAJxq2VOtJA2D/2dsb2JhbABZgw5SVwTKZh4Kh0sBgRAWd4QEAQEBAgEBAQE3NAsQAgEIDigQJwslAgQOBYg6CA3AORePTAeESgWEfAKWZoFSkwGDSWyBBSQc X-IronPort-AV: E=Sophos;i="5.01,767,1400025600"; d="scan'208";a="343781442" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP; 30 Jul 2014 22:00:40 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6UM0dhG010447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 22:00:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 17:00:39 -0500 From: "Larry Kreeger (kreeger)" To: Tom Herbert Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDUc+I5/u44SU2TO/uEBEAfx5u09aOAgABtLwCAAIjTgIAAzUAAgAAT34CAAAUFgIAABKAAgAIym4CAAHZrgP//jqoA Date: Wed, 30 Jul 2014 22:00:39 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.21.126.25] Content-Type: text/plain; charset="us-ascii" Content-ID: <38E4D57A46510B42B5FE7A9783C7D02C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/_QukeKRjnuJD_A__vFe_6MfJ0hQ Cc: David Melman , Marc Binderberger , LISP mailing list list , Dino Farinacci , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 22:00:43 -0000 Hi Tom, First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 for NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly following the VXLAN-GPE header would be an NSH header. One would need to define a new MD Type (not the SFC value of 0x1, specified in draft-quinn-nsh-03). Then you need to make a decision as to whether you want to possibility of your authentication value to be processed by hardware or only software. If you want hardware support, then I would recommend that it not be encoded as a TLV. If you only care about software support, then you could encode the authentication in a TLV using your own organization's TLV Class, or perhaps an IETF TLV Class if you are standardizing it. If you expect hardware to parse and validate the VNI authentication, then I would encode it somewhere within the 20 bytes following the base NSH header and not in a TLV. - Larry On 7/30/14 2:46 PM, "Tom Herbert" wrote: >> I think the intent of NSH is to be generic enough to work at different >> layers. The recent addition of the Metadata Type field in the NSH >>header >> allows for it to be used for purposes beyond SFC. It could >>theoretically >> be used to essentially extend the header of the layer below it (e.g. >> VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 >>bit >> VNI authentication. >> >I'd be interested to see exactly what the headers might look like in >that case. I've tried to extrapolate from the SFC drafts how that >might work but really don't see it... > >Thanks, >Tom > >> - Larry >> >>>Just like any other UDP application. If that packet needs to be >>>encapsulated that is a lower level function. Just like IP packets can go >>>in an MPLS based LSP. >>> >>>> picture? They do mean something about how the packet is handled, >>>>don't >>>>they? >>> >>>I won't answer that because those bit introductions into the design are >>>indeed design bugs IMO. >>> >>>Dino >>>_______________________________________________ >>>nvo3 mailing list >>>nvo3@ietf.org >>>https://www.ietf.org/mailman/listinfo/nvo3 >> From nobody Wed Jul 30 17:16:53 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEA21A02A2 for ; Wed, 30 Jul 2014 17:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 lmI6z4-ZBRMC for ; Wed, 30 Jul 2014 17:16:50 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493181A01BD for ; Wed, 30 Jul 2014 17:16:50 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id rl12so2590841iec.38 for ; Wed, 30 Jul 2014 17:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oh++kpA77WpsiCJTGLBYSR++UoStMHby0wqyni9vIgs=; b=CpyWBcMlc+JJHACJD2kYSdni7odBQrexqbYaO8bHcQtsgvhDoVlG8HZOSR5aFPdwOJ x7xyZDTVaODUIuLKvYDP3eloVV4Sv3ZNVi0TclLCFrqly1uxe+3nhevDzDEhHlszceFt oufvWcQjv2BAvSSdknMojDFGu4KBZ7zavf6kC8ehYmGSEJHujCcAQBAUYQ18V+Ebj5r/ h/jDmtqIrTvHbIYQZ3Byc5JyHrdzWovOdMLn5ezmkX9e7b6R3mm6zUSXIqK1tsObILu2 kxGpkj+1p3IHivg5xgQi0CO1MWVlCXqsFZHiqPh/KbontTkTCQv8eON+qe5NKTssTgpu Ureg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oh++kpA77WpsiCJTGLBYSR++UoStMHby0wqyni9vIgs=; b=Ie1qWtHybs3gQv9pWFzmOxf3g10n2eJwt2HDsmd61MHUybfnqvLixujZHTCBTzreZQ ttzArWqgBfysB1d9gtd30NdCk1ZrGb972JlTo0fl5ImYsbyo/fi3uTY0PMb08x4G+Zs/ bHUTXz+06LpcnuzUmeQTaOKuuan39aNkLO0YWaqK2R+ysMTXu0SoSDWw/H52Gkiec7Ey DRu9OyY74o3Kl9XI0wzOnpF8O7lU74vZzs346kuaAN3x/hV/djUVG+4cUudIJ6c0jk0w 8piCScWgfPPgAqGl81AejeR/1SzBtIe9AaAV1yvuCvreIYwov8IuFC3BeyVyTU8ymE9f hZ7w== X-Gm-Message-State: ALoCoQmX3WxVyzFzd0UAErk4I1oHXYPeRc0aIzWhE7lwl1mvwtp6ntd6YbR9437fj4PP0XX1eaQ2 MIME-Version: 1.0 X-Received: by 10.50.12.38 with SMTP id v6mr58671772igb.29.1406765809578; Wed, 30 Jul 2014 17:16:49 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Wed, 30 Jul 2014 17:16:49 -0700 (PDT) In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> Date: Wed, 30 Jul 2014 17:16:49 -0700 Message-ID: From: Tom Herbert To: "Larry Kreeger (kreeger)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/DKcyv3nYg4ZfQOWZjwaNFHAJ1os Cc: David Melman , Marc Binderberger , LISP mailing list list , Dino Farinacci , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 00:16:52 -0000 On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger) wrote: > Hi Tom, > > First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 for > NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly following > the VXLAN-GPE header would be an NSH header. One would need to define a > new MD Type (not the SFC value of 0x1, specified in draft-quinn-nsh-03). > Then you need to make a decision as to whether you want to possibility of > your authentication value to be processed by hardware or only software. > If you want hardware support, then I would recommend that it not be > encoded as a TLV. If you only care about software support, then you could > encode the authentication in a TLV using your own organization's TLV > Class, or perhaps an IETF TLV Class if you are standardizing it. If you > expect hardware to parse and validate the VNI authentication, then I would > encode it somewhere within the 20 bytes following the base NSH header and > not in a TLV. > Any optional data I define which proves useful in the datapath I may eventually want to implement in HW, and I really wouldn't want to have to make such a decision up front-- so I'll assume anything we'd want to define would need to go into NSH headers in order to keep HW support an option. So then in this model is it correct to say that the we could arbitrarily extend the protocol by using a chain of NSH headers each of which provides 20 bytes of data we can use for optional data and still be "HW friendly"? Thanks, Tom > - Larry > > On 7/30/14 2:46 PM, "Tom Herbert" wrote: > >>> I think the intent of NSH is to be generic enough to work at different >>> layers. The recent addition of the Metadata Type field in the NSH >>>header >>> allows for it to be used for purposes beyond SFC. It could >>>theoretically >>> be used to essentially extend the header of the layer below it (e.g. >>> VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 >>>bit >>> VNI authentication. >>> >>I'd be interested to see exactly what the headers might look like in >>that case. I've tried to extrapolate from the SFC drafts how that >>might work but really don't see it... >> >>Thanks, >>Tom >> >>> - Larry >>> >>>>Just like any other UDP application. If that packet needs to be >>>>encapsulated that is a lower level function. Just like IP packets can go >>>>in an MPLS based LSP. >>>> >>>>> picture? They do mean something about how the packet is handled, >>>>>don't >>>>>they? >>>> >>>>I won't answer that because those bit introductions into the design are >>>>indeed design bugs IMO. >>>> >>>>Dino >>>>_______________________________________________ >>>>nvo3 mailing list >>>>nvo3@ietf.org >>>>https://www.ietf.org/mailman/listinfo/nvo3 >>> > From nobody Wed Jul 30 17:51:25 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4431A00FC; Wed, 30 Jul 2014 17:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 5xdOQlnuGooX; Wed, 30 Jul 2014 17:51:10 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF961A01EF; Wed, 30 Jul 2014 17:51:10 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id w10so2392780pde.18 for ; Wed, 30 Jul 2014 17:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ma2sGzwv2sggSUNgXKtaMLAfYqZk/u88nZy3OWnAKnY=; b=FWLnwy0BGeemPirjRG7jAy2o0NAjOZltLkwHF2bt1Xt92WrX6Jr7bGGd5Vx3IgDgH+ oq96h4GpceCz058QDUsO2WBB7k1kwC5KyP2LvNlKpiaCmpafne73oE5J4n26KvE3M+hj m+Kj4p3U+bWHJqLa3EscQU7iA4NU3UGzaFKKJRFydLw4rGBRa9VBtekMoLW3Kq1HbH8e /oYLqXK/BWBv9SqwTy7FIPzj1CIsaauttf2JOr2KFWtOFmGGZQJEkQ1+Y4JbCxPdeGWb JH3/xBaPNFlt8FBcZVtZL6zVoh52GDoFNSVwuwPqho1ym1pdfvCz8X+gUwp0gQV5waDy 9IKA== X-Received: by 10.66.180.34 with SMTP id dl2mr595251pac.124.1406767870294; Wed, 30 Jul 2014 17:51:10 -0700 (PDT) Received: from [10.169.113.83] (68.65.67.46.static-ip.telepacific.net. [68.65.67.46]) by mx.google.com with ESMTPSA id k8sm3584710pbq.94.2014.07.30.17.51.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 17:51:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Wed, 30 Jul 2014 17:51:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> To: Larry Kreeger X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/4p1uNXRpDBbnRr3xw14DUMKbk7g Cc: Tom Herbert , David Melman , Marc Binderberger , LISP mailing list list , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 00:51:12 -0000 > I can see the O-bit being useful when you want to use port 4341 to = help > ensure that OAM packets use the same path through the network as the = user > data packets. Well there is no reason they wouldn't go the same as the user packets if = the destination IP address was the same. Also, the OAM proposal for LISP = is to measure paths between RLOCs. The same RLOCs that are used for data = packets. You don't need a data-plane header to achieve the same paths. = And again, you give more work for the hardware to do. >=20 >> And P-bit is not needed and the authors indicated the main motivation = was >> to keep consistent with VXLAN so same hardware design could do both. = LISP >> already has port 8473 for L2 frames. >=20 > I assume you meant 8472 (assigned to OTV and used by VXLAN = implementation > pre-IANA assignment). I'm not sure you can technically call this a = LISP > port. Yes, typo. We will call it a port used by LISP because it is documented in = draft-smith-lisp-layer-2. But don't miss the point of referencing it. > And NSH is a service protocol and should run above the transport layer = so >> should have its own port and can address packets anywhere. >=20 > I think the intent of NSH is to be generic enough to work at different > layers. The recent addition of the Metadata Type field in the NSH = header > allows for it to be used for purposes beyond SFC. It could = theoretically > be used to essentially extend the header of the layer below it (e.g. > VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 = bit > VNI authentication. No one is questioning the intent of NSH. But it should use a UDP header = not a VXLAN header. Why is it any different than DNS or SMTP? If the NSH UDP packet gets encapsulated downstream by a VXLAN or LISP = device, so be it. But why should NSH prepend a VXLAN header. And why = would NSH prepend a MAC header before the VXLAN header. I talked to the = authors about this, so it is not news to them. Dino From nobody Wed Jul 30 18:04:51 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06911A02F7; Wed, 30 Jul 2014 18:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 QDjVR7GXGqJl; Wed, 30 Jul 2014 18:04:48 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4251A01E7; Wed, 30 Jul 2014 18:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2611; q=dns/txt; s=iport; t=1406768687; x=1407978287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kjD9dtCNGAPt4yYK5BtP3/ZuiQXHNtM2kM0u4TVjYBI=; b=TC8SN4GMh3NJUqY9kaaaLJGwNUCNgktJ0I/dx+3a5bMIRdtA25lw5WXq AA06acuva03ccb7y5BAgI8ABBXWxGLtgmegO/BL5gF2yS2nh4GW/QsSoq ru7Q5sLE5uojrvDt506Y/9HuLhCe8b0bK9FBSmomWbZ5T0rZUIBLEJu91 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAJaV2VOtJA2N/2dsb2JhbABZgw5SVwTLEIdLAYEIFneEBAEBAwE6PxACAQg2ECERJQIEDgUaiBQDCQgNuS4Nhw4XjR+CLQeESgWZX4IFgVKMXIYlg0lsgUU X-IronPort-AV: E=Sophos;i="5.01,768,1400025600"; d="scan'208";a="65351481" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 31 Jul 2014 01:04:47 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6V14lsk004809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 01:04:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 20:04:46 -0500 From: "Larry Kreeger (kreeger)" To: Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDUc+I5/u44SU2TO/uEBEAfx5u09aOAgABtLwCAAIjTgIAAzUAAgAAT34CAAAUFgIAABKAAgAIym4CAAKoTAP//jnIA Date: Thu, 31 Jul 2014 01:04:45 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.21.126.25] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E8F9B3E562D734B9B3569650F444A57@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/IKL_F8RYgdSzSRvLXeZF48xHwz8 Cc: Tom Herbert , David Melman , Marc Binderberger , LISP mailing list list , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 01:04:50 -0000 On 7/30/14 5:51 PM, "Dino Farinacci" wrote: >> I can see the O-bit being useful when you want to use port 4341 to help >> ensure that OAM packets use the same path through the network as the >>user >> data packets. > >Well there is no reason they wouldn't go the same as the user packets if >the destination IP address was the same. Also, the OAM proposal for LISP >is to measure paths between RLOCs. The same RLOCs that are used for data >packets. You don't need a data-plane header to achieve the same paths. >And again, you give more work for the hardware to do. I'm assuming that routers and switches will be multipathing based on the UDP port numbers, so I would expect different destination UDP ports to take different equal cost paths. > >>=20 >>> And P-bit is not needed and the authors indicated the main motivation >>>was >>> to keep consistent with VXLAN so same hardware design could do both. >>>LISP >>> already has port 8473 for L2 frames. >>=20 >> I assume you meant 8472 (assigned to OTV and used by VXLAN >>implementation >> pre-IANA assignment). I'm not sure you can technically call this a LISP >> port. > >Yes, typo. > >We will call it a port used by LISP because it is documented in >draft-smith-lisp-layer-2. But don't miss the point of referencing it. > >> And NSH is a service protocol and should run above the transport layer >>so >>> should have its own port and can address packets anywhere. >>=20 >> I think the intent of NSH is to be generic enough to work at different >> layers. The recent addition of the Metadata Type field in the NSH >>header >> allows for it to be used for purposes beyond SFC. It could >>theoretically >> be used to essentially extend the header of the layer below it (e.g. >> VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 >>bit >> VNI authentication. > >No one is questioning the intent of NSH. But it should use a UDP header >not a VXLAN header. Why is it any different than DNS or SMTP? I agree that for service chaining, NSH can certainly ride within UDP. I'm referring to using NSH to extend the VXLAN header (or similar encapsulation...I'm not sure what layer to call it). I responded to Tom on this thread regarding a potential use case for this. > >If the NSH UDP packet gets encapsulated downstream by a VXLAN or LISP >device, so be it. But why should NSH prepend a VXLAN header. And why >would NSH prepend a MAC header before the VXLAN header. I talked to the >authors about this, so it is not news to them. > >Dino > > > From nobody Wed Jul 30 18:06:43 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD1F1A02F7; Wed, 30 Jul 2014 18:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 0wfwFqCJQTOq; Wed, 30 Jul 2014 18:06:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9AC1A0076; Wed, 30 Jul 2014 18:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3206; q=dns/txt; s=iport; t=1406768794; x=1407978394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Gtik1BYtqvGpGyCUDDuEnRyOJHmYWLii+Hyau10M9BI=; b=eU2NyQOFmDJwezVVGF5dROBuCAmUNywzeJr3jD+DHGe9XtMFnGP1D52Y Zf6OQAjJx0t3eZvXd4ITwIe44UaK7qHShUaXl3OC4hDzCO7tl1ZgjazWb VIX7u7RK1v8IeV1guJBWznbJA7kfscsgvKrXwKhedoS52dcZaaf8IEcrl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFANKV2VOtJA2G/2dsb2JhbABZgw5SVwTKahwKh0sBgQgWd4QEAQEBAwEBATc0CxACAQgOCh4QJwslAgQOBYhCDcBJF49MB4RKBYR8ApJAhCaBUpMBg0lsgQUkHA X-IronPort-AV: E=Sophos;i="5.01,768,1400025600"; d="scan'208";a="344105176" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2014 01:06:33 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6V16WS9023115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 01:06:32 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 20:06:32 -0500 From: "Larry Kreeger (kreeger)" To: Tom Herbert Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDUc+I5/u44SU2TO/uEBEAfx5u09aOAgABtLwCAAIjTgIAAzUAAgAAT34CAAAUFgIAABKAAgAIym4CAAHZrgP//jqoAgACbaID//5iFgA== Date: Thu, 31 Jul 2014 01:06:31 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.21.126.25] Content-Type: text/plain; charset="us-ascii" Content-ID: <6A2C1CFAFAAF174AB2D2558258B5F949@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/SKEt2L62TJPC1oPEwoFJCuEaXL0 Cc: David Melman , Marc Binderberger , LISP mailing list list , Dino Farinacci , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 01:06:38 -0000 On 7/30/14 5:16 PM, "Tom Herbert" wrote: >On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger) > wrote: >> Hi Tom, >> >> First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 >>for >> NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly >>following >> the VXLAN-GPE header would be an NSH header. One would need to define a >> new MD Type (not the SFC value of 0x1, specified in draft-quinn-nsh-03). >> Then you need to make a decision as to whether you want to possibility >>of >> your authentication value to be processed by hardware or only software. >> If you want hardware support, then I would recommend that it not be >> encoded as a TLV. If you only care about software support, then you >>could >> encode the authentication in a TLV using your own organization's TLV >> Class, or perhaps an IETF TLV Class if you are standardizing it. If you >> expect hardware to parse and validate the VNI authentication, then I >>would >> encode it somewhere within the 20 bytes following the base NSH header >>and >> not in a TLV. >> >Any optional data I define which proves useful in the datapath I may >eventually want to implement in HW, and I really wouldn't want to have >to make such a decision up front-- so I'll assume anything we'd want >to define would need to go into NSH headers in order to keep HW >support an option. So then in this model is it correct to say that the >we could arbitrarily extend the protocol by using a chain of NSH >headers each of which provides 20 bytes of data we can use for >optional data and still be "HW friendly"? No, I would not necessarily say that. I think an arbitrary number of NSH headers makes the expected offset of the payload vary in a similar way that TLVs would. > >Thanks, >Tom > >> - Larry >> >> On 7/30/14 2:46 PM, "Tom Herbert" wrote: >> >>>> I think the intent of NSH is to be generic enough to work at different >>>> layers. The recent addition of the Metadata Type field in the NSH >>>>header >>>> allows for it to be used for purposes beyond SFC. It could >>>>theoretically >>>> be used to essentially extend the header of the layer below it (e.g. >>>> VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 >>>>bit >>>> VNI authentication. >>>> >>>I'd be interested to see exactly what the headers might look like in >>>that case. I've tried to extrapolate from the SFC drafts how that >>>might work but really don't see it... >>> >>>Thanks, >>>Tom >>> >>>> - Larry >>>> >>>>>Just like any other UDP application. If that packet needs to be >>>>>encapsulated that is a lower level function. Just like IP packets can >>>>>go >>>>>in an MPLS based LSP. >>>>> >>>>>> picture? They do mean something about how the packet is handled, >>>>>>don't >>>>>>they? >>>>> >>>>>I won't answer that because those bit introductions into the design >>>>>are >>>>>indeed design bugs IMO. >>>>> >>>>>Dino >>>>>_______________________________________________ >>>>>nvo3 mailing list >>>>>nvo3@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/nvo3 >>>> >> From nobody Wed Jul 30 18:13:35 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E411A016D; Wed, 30 Jul 2014 18:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 yCX8e0Cl0LWr; Wed, 30 Jul 2014 18:13:29 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CE41A0076; Wed, 30 Jul 2014 18:13:29 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id g10so2429537pdj.15 for ; Wed, 30 Jul 2014 18:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/KhUeDB+w9EwPfeDTKfbPgqk81KziAaQRlYSxYvsklA=; b=P2Wt4X6Y4APx0New33DPZbjLhV4D9JtzODlcRP8OIxOSnc//M4p+or9b8DvDus9BR8 wNvC0+M6zau8pz79B9DTPs6z4l028b73JHR5HtufDVPa23IkSCt9ODwud9jyaVim8T/Y au7riv510/wAuZD3u01CyA1gpC15X6k2kzT6L0NJiQgzxU70Rjw2U3kl1qHRMfDvzeg9 E6qta/xYY72xggvBWybnFA204kgI4f0OVdntXtipFGGrZvfxGJLhR3Aec41IhD9eJo42 6BvZfiBhLO2kwKCDYhBmwg8CbyVek7KUxHQRh61XMfHOTxX1kRxuSsygKMX0g2stecbo VZwg== X-Received: by 10.70.91.73 with SMTP id cc9mr8777198pdb.138.1406769209211; Wed, 30 Jul 2014 18:13:29 -0700 (PDT) Received: from [10.169.113.83] (68.65.67.46.static-ip.telepacific.net. [68.65.67.46]) by mx.google.com with ESMTPSA id qw8sm13244578pab.17.2014.07.30.18.13.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 18:13:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Wed, 30 Jul 2014 18:13:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> To: Larry Kreeger X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/9UV2vtiSr6toJ9C5AOcL-MIuCw0 Cc: Tom Herbert , David Melman , Marc Binderberger , LISP mailing list list , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 01:13:31 -0000 > I'm assuming that routers and switches will be multipathing based on = the > UDP port numbers, so I would expect different destination UDP ports to > take different equal cost paths. Well if OAM is going to be effective, messages need to be sent from any = pair of ports that yield 0 through N modulus so multiple paths can be = determined. So it doesn't matter with the port number values you use, = those control packets will be ECMPed as well. If you are also inferring that you want the OAM packets to go through = the same data-path of each device on the path, then you will have to put = TLVs in the data path, which is traditionally not prudent. See my Puneet = reference from previous email. Dino From nobody Wed Jul 30 18:55:30 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566CB1A030A; Wed, 30 Jul 2014 18:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 rO_OWvq_6Mew; Wed, 30 Jul 2014 18:55:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039101A01CA; Wed, 30 Jul 2014 18:55:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT53142; Thu, 31 Jul 2014 01:55:19 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 02:55:17 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 09:55:15 +0800 From: Xuxiaohu To: "Larry Kreeger (kreeger)" , Dino Farinacci , Marc Binderberger Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPrD8x8HabDXKfWkOqJ8h/w9M6lZu5abCw Date: Thu, 31 Jul 2014 01:55:15 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829A473@NKGEML512-MBS.china.huawei.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/E5ntHfj6bmwBBNsIRuH6LTV8fII Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , "sfc@ietf.org" , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 01:55:24 -0000 > >And NSH is a service protocol and should run above the transport layer > >so should have its own port and can address packets anywhere. >=20 > I think the intent of NSH is to be generic enough to work at different la= yers. > The recent addition of the Metadata Type field in the NSH header allows f= or it to > be used for purposes beyond SFC. It could theoretically be used to essen= tially > extend the header of the layer below it (e.g. > VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 bit= VNI > authentication. Hi Larry, If the Metadata Type field in the NSH header is going to be used for purpos= es beyond SFC, it seem much better to make the metadata-specific header and= the service-path header as independent as possible from the beginning.=20 Best regards, Xiaohu From nobody Thu Jul 31 05:56:30 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D5E1A0005 for ; Thu, 31 Jul 2014 05:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 wdoP7iAwtbzL for ; Thu, 31 Jul 2014 05:56:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AAA1A0118 for ; Thu, 31 Jul 2014 05:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2010; q=dns/txt; s=iport; t=1406811388; x=1408020988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AQP/Lib3CvZ1KV1EG4Sk8Lc4xDT8MDRiuSHjLrQHuXE=; b=XRN/TiUJSlWVpfLuZwf3H2yn/liFN6USZC9Oz1yDNVi02zZo3GAVqbzm 4qKKkuNgvZ3XVBAoI1w4C4oh2yB+tB0MCsWgRopi/MtN4qqOC7jCnJ4zQ 2+g3KGYLWgUJ6NKt4t77JulYKpIORMST79Z1XqFF8bDmJt9ybDHdKagqj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFALM82lOtJV2Y/2dsb2JhbABZgw5SVwTLLIdLAYEGFneEAwEBAQECAXkFCwIBCA4KLjIlAgQOBYg6CA29FRePGTMHgy+BGwEEhHwCkkCEJoFSkwGDSWyBBSQc X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208";a="344101489" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 31 Jul 2014 12:56:15 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6VCuEoP004526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 12:56:14 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 07:55:27 -0500 From: "Paul Quinn (paulq)" To: Tom Herbert Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPrEG7ecH2kH2hrEaqcGl1IoWHLpu5pL+AgADULQA= Date: Thu, 31 Jul 2014 12:56:14 +0000 Message-ID: <386F5815-C806-4C4D-818F-14B4E8E0F2A1@cisco.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.228] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/ocU1pvmz-p5KDpBEWSfmZlNCY-k Cc: David Melman , Marc Binderberger , "Larry Kreeger \(kreeger\)" , Dino Farinacci , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 12:56:30 -0000 On Jul 30, 2014, at 8:16 PM, Tom Herbert wrote: > On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger) > wrote: >> Hi Tom, >>=20 >> First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 fo= r >> NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly followin= g >> the VXLAN-GPE header would be an NSH header. One would need to define a >> new MD Type (not the SFC value of 0x1, specified in draft-quinn-nsh-03). >> Then you need to make a decision as to whether you want to possibility o= f >> your authentication value to be processed by hardware or only software. >> If you want hardware support, then I would recommend that it not be >> encoded as a TLV. If you only care about software support, then you cou= ld >> encode the authentication in a TLV using your own organization's TLV >> Class, or perhaps an IETF TLV Class if you are standardizing it. If you >> expect hardware to parse and validate the VNI authentication, then I wou= ld >> encode it somewhere within the 20 bytes following the base NSH header an= d >> not in a TLV. >>=20 > Any optional data I define which proves useful in the datapath I may > eventually want to implement in HW, and I really wouldn't want to have > to make such a decision up front-- so I'll assume anything we'd want > to define would need to go into NSH headers in order to keep HW > support an option. So then in this model is it correct to say that the > we could arbitrarily extend the protocol by using a chain of NSH > headers each of which provides 20 bytes of data we can use for > optional data and still be "HW friendly"? You can=92t generalize hardware parsing like that. The key for easy of par= sing is fixed sizes and known offsets. Stacking headers changes that. Tha= t isn=92t to say you couldn=92t do what you suggest, but it would be more c= omplex and limits the value of the simple fixed size header. From nobody Thu Jul 31 08:31:32 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F2A1A00D7 for ; Thu, 31 Jul 2014 08:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 eiOGLXy2AFXl for ; Thu, 31 Jul 2014 08:31:29 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04D71A00AB for ; Thu, 31 Jul 2014 08:31:28 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so4034920iec.30 for ; Thu, 31 Jul 2014 08:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lAOCoxfmxkG6Sj1ktcyLoYJ/4ZRtOLmJlgQI91TtYYg=; b=PPOXlBmDKPp1k6RQ0WsQ+DeOwJDXeZG2lnlzafCQ0TKmz2GL1tzPrUKvwSqdiopWXK r/DCbWPrzoLO14nL1xAJBLz7TE/zSUTgJ1QnskYffxmvp+5VVlzItVzp890RWpO6H9UH PMqVKVBfKIuSKtrx3AQcrCpeqBYE7LcchgoRUXAGXIGZBCwZgRJYqVmoJ3fJrt3LrHM7 oMM7yboCf94ZJLctj5CBChrqgczs+ocYjAPZkQ0LQIHRW0sna72RG3LPV83evsupmWbz SZbH+UqYaDXTRYCzXmvZcr2RkCt3v12loRgSLb+EqZMtHoItkMZWkN3NpAwfHEGdB2/J UTqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lAOCoxfmxkG6Sj1ktcyLoYJ/4ZRtOLmJlgQI91TtYYg=; b=hqxNO/hywJR1HthtfEKORmFb/w/dhI7OmMS4Ywdh+CGxG5Vk+9JFHPtibHwRevdOds rzff/wAUpuqOw6aocuxB6F7zifZRCrTsdU0sD4cPb1vZ6g+KAnc+q9GaIl3j9BGyNahr ScpmuCM++rA1Sf/ViExyiQwQlhe7AogVGGfJoS86uk6L2gLvhbcMmUR2JEtfgfHRnsAI 6/+2XjjZ+KMdxa69YgePsowcUcKZQXKM6mc9OFuxc5siYlEMZB739Pr7B18X42Hvb4yN EkG43eqmY5gGIYayWIpEKAzLXUTXLTElIEZQpMC3d7xruRdBnP94/MUwEcl+ANpZwOGw SqXw== X-Gm-Message-State: ALoCoQkGEEAgjqAttaIW1lkQjkfp+9zUnUYrFaayRmc6cWXz44qvinS58j94bgz1NIktxhHV44pX MIME-Version: 1.0 X-Received: by 10.50.43.234 with SMTP id z10mr66614773igl.28.1406820688210; Thu, 31 Jul 2014 08:31:28 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Thu, 31 Jul 2014 08:31:27 -0700 (PDT) In-Reply-To: <386F5815-C806-4C4D-818F-14B4E8E0F2A1@cisco.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <386F5815-C806-4C4D-818F-14B4E8E0F2A1@cisco.com> Date: Thu, 31 Jul 2014 08:31:27 -0700 Message-ID: From: Tom Herbert To: "Paul Quinn (paulq)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/6H_UPdORxKDtMwY7BYs0_8uWvZA Cc: David Melman , Marc Binderberger , "Larry Kreeger \(kreeger\)" , Dino Farinacci , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 15:31:30 -0000 On Thu, Jul 31, 2014 at 5:56 AM, Paul Quinn (paulq) wrote= : > > > > On Jul 30, 2014, at 8:16 PM, Tom Herbert wrote: > >> On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger) >> wrote: >>> Hi Tom, >>> >>> First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 f= or >>> NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly followi= ng >>> the VXLAN-GPE header would be an NSH header. One would need to define = a >>> new MD Type (not the SFC value of 0x1, specified in draft-quinn-nsh-03)= . >>> Then you need to make a decision as to whether you want to possibility = of >>> your authentication value to be processed by hardware or only software. >>> If you want hardware support, then I would recommend that it not be >>> encoded as a TLV. If you only care about software support, then you co= uld >>> encode the authentication in a TLV using your own organization's TLV >>> Class, or perhaps an IETF TLV Class if you are standardizing it. If yo= u >>> expect hardware to parse and validate the VNI authentication, then I wo= uld >>> encode it somewhere within the 20 bytes following the base NSH header a= nd >>> not in a TLV. >>> >> Any optional data I define which proves useful in the datapath I may >> eventually want to implement in HW, and I really wouldn't want to have >> to make such a decision up front-- so I'll assume anything we'd want >> to define would need to go into NSH headers in order to keep HW >> support an option. So then in this model is it correct to say that the >> we could arbitrarily extend the protocol by using a chain of NSH >> headers each of which provides 20 bytes of data we can use for >> optional data and still be "HW friendly"? > > > You can=E2=80=99t generalize hardware parsing like that. The key for eas= y of parsing is fixed sizes and known offsets. Stacking headers changes th= at. That isn=E2=80=99t to say you couldn=E2=80=99t do what you suggest, bu= t it would be more complex and limits the value of the simple fixed size he= ader. > I'm not trying generalize hardware parsing, I was trying to extrapolate how to use NSH to allow different meta data. Unless I misunderstand, NSH has similar properties to TLVs with the exception that they are fixed size. I do agree that fixed sizes and known offset are important for easy parsing, which is precisely why I'm leery about anything that looks like TLVs in such a low level data path. The major parsing problem with TLVs (and I presume NSH if more than one header is allowed) is that the number of possible header combinations is combinatorial. For example, if there are 5 TLVs this generates 150 possible combinations. If we use optional flag-fields like in GUE (based on GRE) there would only be 32 possible combinations. The latter is much more amenable to HW parsing techniques like say a TCAM, not to mention the overhead to describe each TLV potentially increases TCAM width. We have already verified that both NICs and switches are capable of parsing GRE with various combinations of the defined variable headers (keyid, seqnum, csum). I take this as evidence that the is method of extensibility is HW friendly. From nobody Thu Jul 31 08:45:46 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFC91B2935; Thu, 31 Jul 2014 08:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QJPO_BO05l2a; Thu, 31 Jul 2014 08:45:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A8E1B286C; Thu, 31 Jul 2014 08:45:38 -0700 (PDT) Received: from BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) by BY2PR03MB125.namprd03.prod.outlook.com (10.242.36.14) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 31 Jul 2014 15:45:29 +0000 Received: from BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.211]) by BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.211]) with mapi id 15.00.0995.014; Thu, 31 Jul 2014 15:45:29 +0000 From: Pankaj Garg To: "Larry Kreeger (kreeger)" , Tom Herbert Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDVMCB+3Ia6AEuZwp+KZdt7RJu0odGAgABtLwCAAIjUgIAAzUAAgAAT3oCAAAUFgIAABKAAgAKn94CAAAEQgIAABAWAgAAmDICAAA3jgIAA9NLw Date: Thu, 31 Jul 2014 15:45:28 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [125.62.209.8] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(377454003)(24454002)(199002)(51704005)(164054003)(13464003)(479174003)(4396001)(64706001)(15202345003)(101416001)(95666004)(77096002)(76176999)(50986999)(74316001)(99286002)(87936001)(33646002)(77982001)(107046002)(54356999)(106356001)(85852003)(46102001)(92566001)(20776003)(15975445006)(99396002)(85306003)(81542001)(21056001)(93886003)(74662001)(76482001)(74502001)(81342001)(19580405001)(31966008)(86612001)(76576001)(86362001)(83072002)(80022001)(66066001)(79102001)(106116001)(105586002)(19580395003)(2656002)(83322001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB125; H:BY2PR03MB128.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/JMCyuoL6iSDe4JA9rA-wheYfsxQ Cc: David Melman , Marc Binderberger , LISP mailing list list , Dino Farinacci , "nvo3@ietf.org" Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 15:45:42 -0000 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Larry Kreeger > (kreeger) > Sent: Wednesday, July 30, 2014 6:07 PM > To: Tom Herbert > Cc: David Melman; Marc Binderberger; LISP mailing list list; Dino Farinac= ci; > nvo3@ietf.org > Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn- > vxlan-gpe-03 >=20 >=20 >=20 > On 7/30/14 5:16 PM, "Tom Herbert" wrote: >=20 > >On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger) > > wrote: > >> Hi Tom, > >> > >> First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 > >>for NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly > >>following the VXLAN-GPE header would be an NSH header. One would > >>need to define a new MD Type (not the SFC value of 0x1, specified in > >>draft-quinn-nsh-03). > >> Then you need to make a decision as to whether you want to > >>possibility of your authentication value to be processed by hardware > >>or only software. > >> If you want hardware support, then I would recommend that it not be > >>encoded as a TLV. If you only care about software support, then you > >>could encode the authentication in a TLV using your own > >>organization's TLV Class, or perhaps an IETF TLV Class if you are > >>standardizing it. If you expect hardware to parse and validate the > >>VNI authentication, then I would encode it somewhere within the 20 > >>bytes following the base NSH header and not in a TLV. > >> > >Any optional data I define which proves useful in the datapath I may > >eventually want to implement in HW, and I really wouldn't want to have > >to make such a decision up front-- so I'll assume anything we'd want to > >define would need to go into NSH headers in order to keep HW support an > >option. So then in this model is it correct to say that the we could > >arbitrarily extend the protocol by using a chain of NSH headers each of > >which provides 20 bytes of data we can use for optional data and still > >be "HW friendly"? >=20 > No, I would not necessarily say that. I think an arbitrary number of NSH > headers makes the expected offset of the payload vary in a similar way th= at > TLVs would. [PG] The idea here is that TLV provides a way for the software to experimen= t and quickly light up new features without requiring changes to NIC offloa= ds. Once the hardware support is needed for those, those TLVs can be conver= ted to standard format metadata and put in the fixed header portion of the = NSH header. Using different MDType, one can have a 20-byte fixed header or = larger/smaller in future for different MDType. This provides a lot of exten= sibility in a way that is both hardware and software friendly. >=20 > > > >Thanks, > >Tom > > > >> - Larry > >> > >> On 7/30/14 2:46 PM, "Tom Herbert" wrote: > >> > >>>> I think the intent of NSH is to be generic enough to work at > >>>>different layers. The recent addition of the Metadata Type field > >>>>in the NSH header allows for it to be used for purposes beyond SFC. > >>>>It could theoretically be used to essentially extend the header of > >>>>the layer below it (e.g. > >>>> VXLAN/LISP). e.g. I think this could be used for Tom to carry his > >>>>64 bit VNI authentication. > >>>> > >>>I'd be interested to see exactly what the headers might look like in > >>>that case. I've tried to extrapolate from the SFC drafts how that > >>>might work but really don't see it... > >>> > >>>Thanks, > >>>Tom > >>> > >>>> - Larry > >>>> > >>>>>Just like any other UDP application. If that packet needs to be > >>>>>encapsulated that is a lower level function. Just like IP packets > >>>>>can go in an MPLS based LSP. > >>>>> > >>>>>> picture? They do mean something about how the packet is handled, > >>>>>>don't they? > >>>>> > >>>>>I won't answer that because those bit introductions into the design > >>>>>are indeed design bugs IMO. > >>>>> > >>>>>Dino > >>>>>_______________________________________________ > >>>>>nvo3 mailing list > >>>>>nvo3@ietf.org > >>>>>https://www.ietf.org/mailman/listinfo/nvo3 > >>>> > >> >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Thu Jul 31 14:09:23 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306BA1A0173; Thu, 31 Jul 2014 14:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 DKmzXjvCaDdP; Thu, 31 Jul 2014 14:09:20 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3281A010A; Thu, 31 Jul 2014 14:09:19 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-0a-53da5aa66894 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9B.6E.25146.6AA5AD35; Thu, 31 Jul 2014 17:03:02 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 31 Jul 2014 17:09:10 -0400 From: Eric Gray To: Dino Farinacci , Larry Kreeger Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDTgKnTo8JzqEinUCL6aopzsZu05OCAgABtLwCAAIjTgIAAzUAAgAAT3oCAAAUGgIAABJ8AgAKZtgCAAEbGgIAAAm4AgAEB1ZA= Date: Thu, 31 Jul 2014 21:09:09 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> In-Reply-To: <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLrHT3dZ1K1gg0eTFSz+fVzMaNG++xqj xYI3i1ksppxVt5h95T+zxdP5khb7L5xmcWD3mPJ7I6vHzll32T0WbCr1WLLkJ5PH5IUXmT1a V3ezBLBFcdmkpOZklqUW6dslcGV8+7uZpeCaYMX73Q8ZGxin8nUxcnJICJhInFm+iBXCFpO4 cG89WxcjF4eQwFFGidkfp7FAOMsZJdZ+38kOUsUmoCFx7M5axi5GDg4RAW+J+xOYQGqYBXYy Siw4spgNpEZYIFSi7+M0ZhBbRCBM4uDH1awQdpnEog+9jCA2i4CqxJlVN8Bm8gr4Shw/3Ai1 bB6rxM8lk9hAFnAK2Er8eZsIUsMIdN33U2uYQGxmAXGJW0/mM0FcLSCxZM95ZghbVOLl439Q 3yhJTFp6jhWiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsY OUqLU8ty040MNzECY++YBJvjDsYFnywPMQpwMCrx8C4QvhUsxJpYVlyZe4hRmoNFSZxXs3pe sJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGzuLLX74UG5tNb8sW/jRNLLMsrGk+w9V9rJd5 atgKr99jP7VzzyzJJctPJX/W6NPlS8nxlflU+PKLmarv7aMtW561+P3fumKj2vkti//u4xI8 dKClVu6gk5iL4t8owQnKflcrbK+YSE4uXOL6QP1DtbPPmUc/X/Ite5g+IS5x6YGAgnimyNgd SizFGYmGWsxFxYkAXNYFzJ4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/6_FVgkbFVpCzjQ2BnkqMHPvRirM Cc: David Melman , "nvo3@ietf.org" , Marc Binderberger , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 21:09:22 -0000 Dino, Would you re-phrase your response? I am having some trouble parsing it, so= =20 I must be missing something. First, I think (when you said "... sent from any pair of ports ...") you me= ant to say "... sent with any pair of ports ..." - but this is a guess. As for making OAM messages traverse the exact same path as data, this is=20 what OAM is expected to do. In essence, if data follows a path that involv= es a non-zero number of gates, while OAM does not, the successful delivery of OAM is only an approximate indication of the data-path integrity. Any H/W that data has to go through, and OAM does not go through, could fail and we would see an OAM indication of a valid path through which data either would not go, or would be diverted in some unexpected way. Ordinarily, this should not be a problem for the hardware, as (ordinarily) = the OAM is indistinguishable from data. The hardware works no harder to push OAM than it would to push an equivalent amount of data. So, what is the problem again? -- Eric -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci Sent: Wednesday, July 30, 2014 9:13 PM To: Larry Kreeger Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list list; n= vo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxla= n-gpe-03 > I'm assuming that routers and switches will be multipathing based on=20 > the UDP port numbers, so I would expect different destination UDP=20 > ports to take different equal cost paths. Well if OAM is going to be effective, messages need to be sent from any pai= r of ports that yield 0 through N modulus so multiple paths can be determin= ed. So it doesn't matter with the port number values you use, those contro= l packets will be ECMPed as well. If you are also inferring that you want the OAM packets to go through the s= ame data-path of each device on the path, then you will have to put TLVs in= the data path, which is traditionally not prudent. See my Puneet reference= from previous email. Dino _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From nobody Thu Jul 31 15:18:13 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AE01A01E1; Thu, 31 Jul 2014 15:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 twuKli6O3K7p; Thu, 31 Jul 2014 15:17:58 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF92E1A01D2; Thu, 31 Jul 2014 15:17:57 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so5412078vcb.28 for ; Thu, 31 Jul 2014 15:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IR78cfynVZAXP+vHYRyIQ5elqW+9YwQC2wbK9LLFfKI=; b=nAZrVsFekhJLF74K3LBaneJTAVQOYGUthL5SAgjp6OsZ3/Fgtfq8wGMyyxNZSzNy+V vhBeVTup78KF3XqIW/C5qOh8BPnkMlRqWRTTDKcAxjJV1o2vfsNKBRJeRI1v6sC7mDY+ qgpZd4fy+06jjeEERo8bpdAplH4HcHA5igNgoQXR25vtuTAmFAN97HTIm5RmlEKM6t4t lsVJwspkxLJTuG2J3h/mLwlTM/CwQLkYLvkeR58zUyMhDs1leulnx/dAdRPtri5aGWqh 08p7Lr+q5Be1wlAgLEc/GISHgKY12Mml8O6fWB1k3DUqA3DdZkxyOqO4xJSbqkgD9bYL SXBA== MIME-Version: 1.0 X-Received: by 10.52.232.200 with SMTP id tq8mr1332451vdc.32.1406845076842; Thu, 31 Jul 2014 15:17:56 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 31 Jul 2014 15:17:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Jul 2014 15:17:56 -0700 Message-ID: From: Greg Mirsky To: "Tissa Senevirathne (tsenevir)" Content-Type: multipart/alternative; boundary=089e0122f5fa0f2f1a04ff84a517 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/wtVFW8Ut6Xt9deEKZ_HUCWpMLKU Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:18:02 -0000 --089e0122f5fa0f2f1a04ff84a517 Content-Type: text/plain; charset=UTF-8 Hi Tissa, authors, et. al, I've read documents and would like to clarify scope of these documents. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there would not be connectivity verification. And the performance measurement is the big part of OAM as well as protection coordination, defect alarms, and etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents? Regards, Greg On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) < tsenevir@cisco.com> wrote: > All > > > > We have published YANG model for OAM. #1 draft below place the generic > framework for OAM, that can be augmented for different technologies. #2 and > #3 are application of the concept to NVO3 and TRILL, > > > > 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ > > 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ > > 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ > > > > Please review and share your comments > > > > Thanks > > Tissa > > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > --089e0122f5fa0f2f1a04ff84a517 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tissa, authors, et. al,
I'v= e read documents and would like to clarify scope of these documents. OAM is= not limited to ping and traceroute functions. It even not limited to conti= nuity check. And in connectionless networks there would not be connectivity= verification. And the performance measurement is the big part of OAM as we= ll as protection coordination, defect alarms, and etc. Hence my question, i= s it in plans of the authors to address all of OAM in respective documents?=

Regards,
Greg

On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevi= rathne (tsenevir) <tsenevir@cisco.com> wrote:

All

=C2=A0

We have published YANG model for OAM. #1 draft below= place the generic framework for OAM, that can be augmented for different t= echnologies. #2 and #3 are application of the concept to NVO3 and TRILL,=

=C2=A0

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://datatracker.ietf.org/doc/draft-tissa= -netmod-oam/

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://datatracker.ietf.org/doc/draft-ti= ssa-nvo3-yang-oam/

3.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://datatracker.ietf.org/doc/draft-t= issa-trill-yang-oam/

=C2=A0

Please review and share your comments<= /p>

=C2=A0

Thanks

Tissa

=C2=A0

=C2=A0


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3


--089e0122f5fa0f2f1a04ff84a517-- From nobody Thu Jul 31 16:22:54 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955601A02CF; Thu, 31 Jul 2014 16:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 KDDDRZSdg2a7; Thu, 31 Jul 2014 16:22:50 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205A61A02A3; Thu, 31 Jul 2014 16:22:50 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id lj1so4553236pab.19 for ; Thu, 31 Jul 2014 16:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mO2JIIMPBtXIcq+lhJMXD1LMW+OsjyP9USUQSjsF/L4=; b=NAGkXRTF2BIHa+tXSBmc9EyrpD68CAdIhlup7bMlkYwcmDfQlS3kCunduvsDINoZBM PK4Nlr1JoMIk4YggtLuDT0ObUu58tNnmKNBgFaJ8ow5N8vN7q6Gqfw7aIvj+xcsLvlO5 raTLgVHU4sv20Z+9GVF9ZfQuxDMDVVpbwKqbXbUJ/DFGIpjRdC4XtyVtq9E6PLexrd1s ewfuAA3Uj30nKG3CPZvXZBRBgMh2OvcRCXiXeOwJK7sfPB3na9uYwfFtErAusi28H66g dtO44vsdGb+UIYjwfLDjIGvS9PUptU7RNf3KbowORauq3fzod96enn/aI2iC6KrmP2FD LeXg== X-Received: by 10.66.161.194 with SMTP id xu2mr1513171pab.128.1406848969789; Thu, 31 Jul 2014 16:22:49 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id gu4sm6660202pbb.54.2014.07.31.16.22.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 16:22:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> Date: Thu, 31 Jul 2014 16:16:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> To: Eric Gray X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/Lue_ov7-4wec5JHCM0h8FUJ6cFM Cc: Marc Binderberger , LISP mailing list list , "nvo3@ietf.org" , David Melman , Larry Kreeger , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:22:52 -0000 > Dino, >=20 > Would you re-phrase your response? I am having some trouble parsing = it, so=20 > I must be missing something. >=20 > First, I think (when you said "... sent from any pair of ports ...") = you meant to > say "... sent with any pair of ports ..." - but this is a guess. Yes "with" is a better way of stating it. > As for making OAM messages traverse the exact same path as data, this = is=20 > what OAM is expected to do. In essence, if data follows a path that = involves Good luck. I do not how you will be able to control each ECMP path at = each path across different vendors as well as the same vendor with = different hashing algorithms. One needs to argue if you really need the granuarlity for the complexity = that will needed to get this partially correct. > a non-zero number of gates, while OAM does not, the successful = delivery of > OAM is only an approximate indication of the data-path integrity. Any = H/W > that data has to go through, and OAM does not go through, could fail = and we > would see an OAM indication of a valid path through which data either = would > not go, or would be diverted in some unexpected way. Well I think LISP RLOC-probing is good enough, but I am biased. ;-) > Ordinarily, this should not be a problem for the hardware, as = (ordinarily) the > OAM is indistinguishable from data. The hardware works no harder to = push > OAM than it would to push an equivalent amount of data. If an ITR sends a packet the ETR's address, the middle boxes do not know = if it is a control-packet versus a data-packet. > So, what is the problem again? I am trying to avoid problems. Seems like things are being = over-engineered. Again. Dino P.S. Sorry I keep being negative. And if one person says shut up, I'll = stop posting. >=20 > -- > Eric >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci > Sent: Wednesday, July 30, 2014 9:13 PM > To: Larry Kreeger > Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list = list; nvo3@ietf.org > Subject: Re: [nvo3] Comments on = http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >=20 >> I'm assuming that routers and switches will be multipathing based on=20= >> the UDP port numbers, so I would expect different destination UDP=20 >> ports to take different equal cost paths. >=20 > Well if OAM is going to be effective, messages need to be sent from = any pair of ports that yield 0 through N modulus so multiple paths can = be determined. So it doesn't matter with the port number values you = use, those control packets will be ECMPed as well. >=20 > If you are also inferring that you want the OAM packets to go through = the same data-path of each device on the path, then you will have to put = TLVs in the data path, which is traditionally not prudent. See my Puneet = reference from previous email. >=20 > Dino >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Thu Jul 31 16:48:42 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7EA1A0301; Thu, 31 Jul 2014 16:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Ae6ZX4jkrm7a; Thu, 31 Jul 2014 16:48:38 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A051A0080; Thu, 31 Jul 2014 16:48:37 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hy4so5583197vcb.13 for ; Thu, 31 Jul 2014 16:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sge4oNtRxrM8fZ+UfI5apucWM0vTaalAtmc/COBoa1k=; b=U5HLBDUknIvggfeW5Ff1XgKL3tsyanxURJ84l/E4SNdt5xscksiRIbAqrfc186l4PN 6FcJJtDek73yeXpwnWjmdAhcLOWr93dV9GxkK7h7/eW5cVAJiA7lJYrvCvymbW7u/K82 NLPal+hxgDyeSk1pjmigh9w7x95qW06u+T0URGbJzJi0c+AtLvI7z8KOVnjYGmVBGBqJ uYnsR5HBaNGp8VszbhkQjl1Rf9sj0df5sgJESMGUzJfus+EddKbTcrqbQMEJ1+bH5Ma6 5jJeXfRTRqvTJ/VFefYj3m/PJRSD6xLzHBI3mtXRaJdzr5B0bPpotlFyqtRRwTbeSzri S6hA== MIME-Version: 1.0 X-Received: by 10.52.232.200 with SMTP id tq8mr1747682vdc.32.1406850516525; Thu, 31 Jul 2014 16:48:36 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 31 Jul 2014 16:48:36 -0700 (PDT) In-Reply-To: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> Date: Thu, 31 Jul 2014 16:48:36 -0700 Message-ID: From: Greg Mirsky To: "O'Connor, Don" Content-Type: multipart/alternative; boundary=089e0122f5fa4a297104ff85e9c4 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/fdSNH1OsvVryl-so4ZTtscwAd6I Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , "Tissa Senevirathne \(tsenevir\)" , Tissa Senevirathne , "opsawg@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:48:40 -0000 --089e0122f5fa4a297104ff85e9c4 Content-Type: text/plain; charset=UTF-8 Hi Don, thank you for the reference. And I'd point that ITU SG15 is working on standardizing "generic protocol-neutral management information model" for transport network, including OAM. Hence my question, What is the scope of these documents? Regards, Greg On Thu, Jul 31, 2014 at 4:31 PM, O'Connor, Don wrote: > Tissa, Greg, all > > > > Metro Ethernet Forum has already standardized Yang Modules for Ethernet > Service OAM Performance Monitoring and Fault Management. Please see MEF 38 > and 39 > > > > http://metroethernetforum.org/carrier-ethernet/technical-specifications > > > > Regards > > > > Don > > > > *From:* L2vpn [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Tissa > Senevirathne > *Sent:* Thursday, July 31, 2014 5:53 PM > *To:* Greg Mirsky; Tissa Senevirathne (tsenevir) > > *Cc:* l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; > trill@ietf.org > *Subject:* Re: [nvo3] YANG models for OAM > > > > Greg > > > > Yes it is, generic YANG model steup the base framework. It can be extended > to add tools as well as other elements as well technology deviations. > Alarms etc either be part of this document will be a separate document that > specifies them. That is the reason we have designed the model as modular as > possible and extensible as possible. > > > > Please let us know if any of the parts are not extensible or not modular > enough. > > > > Thanks > > Tissa > > > > On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: > > > > Hi Tissa, authors, et. al, > > I've read documents and would like to clarify scope of these documents. > OAM is not limited to ping and traceroute functions. It even not limited to > continuity check. And in connectionless networks there would not be > connectivity verification. And the performance measurement is the big part > of OAM as well as protection coordination, defect alarms, and etc. Hence my > question, is it in plans of the authors to address all of OAM in respective > documents? > > Regards, > > Greg > > > > On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) < > tsenevir@cisco.com> wrote: > > All > > > > We have published YANG model for OAM. #1 draft below place the generic > framework for OAM, that can be augmented for different technologies. #2 and > #3 are application of the concept to NVO3 and TRILL, > > > > 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ > > 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ > > 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ > > > > Please review and share your comments > > > > Thanks > > Tissa > > > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > --089e0122f5fa4a297104ff85e9c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Don,
thank you for the referenc= e. And I'd point that ITU SG15 is working on standardizing "generic protocol-neutral management informatio= n model" for transport network, including OAM. Hence my question, What= is the scope of these documents?

Regards,
Greg

On Thu, Jul 31, 2014 at 4:31 PM, O'Connor,= Don <don.oconnor@us.fujitsu.com> wrote:

Tissa, Greg, all<= /u>

=C2=A0=

Metro Ethernet Forum has al= ready standardized Yang Modules for Ethernet Service OAM Performance Monito= ring and Fault Management. Please see MEF 38 and 39

=C2=A0=

= http://metroethernetforum.org/carrier-ethernet/technical-specifications=

=C2=A0=

Regards

=C2=A0=

Don

=C2=A0=

From: L2vpn [m= ailto:l2vpn-bou= nces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)


Cc: l2vpn@ietf.o= rg; opsawg@ietf.or= g; nvo3@ietf.org= ; netmod@ietf.org;= trill@ietf.org
Subject: Re: [nvo3] YANG models for OAM

=C2=A0

Greg<= /u>

=C2=A0

Yes it is, generic YANG model steup the ba= se framework. It can be extended to add tools as well as other elements as = well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. That is the= reason we have designed the model as modular as possible and extensible as= possible.

=C2=A0

Please let us know if any of the parts are= not extensible or not modular enough.

=C2=A0

Thanks

Tissa

=C2=A0

On= Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

=C2=A0

Hi Tissa, autho= rs, et. al,

I've read documents and would like to clarify scope of these docu= ments. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there= would not be connectivity verification. And the performance measurement is= the big part of OAM as well as protection coordination, defect alarms, and= etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents?=

Regards,=

Greg<= /u>

=C2=A0

On Tue, Jun 10,= 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:<= u>

All

=C2=A0

We have publish= ed YANG model for OAM. #1 draft below place the generic framework for OAM, = that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

=C2=A0

=C2=A0

Please review a= nd share your comments

=C2=A0

Thanks

Tissa=

=C2=A0

=C2=A0


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

=C2=A0

=C2=A0


--089e0122f5fa4a297104ff85e9c4-- From nobody Thu Jul 31 16:49:13 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFC91A0080; Thu, 31 Jul 2014 16:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 tDh5YZej6E02; Thu, 31 Jul 2014 16:49:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB171A0301; Thu, 31 Jul 2014 16:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19801; q=dns/txt; s=iport; t=1406850544; x=1408060144; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Svw2C60Lw80f7gy7vE3gbzXzQZOfSehj3k6z268wzis=; b=ccyoKFSB6y6+ZdMKxvTKU9KZXMh2zjvSVtaVheLKkYFEphcCksdRttAj 64DQrHzpVyNim+CRbohcg+uwfT4pwhoWFokXx5WXJt6B67sLu+gIhWtqa kdDWk5qHX7CksEGILxNgNpTqno4os0OGXjqrXxIWy6RTPMJ4s3uOG31cS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0IAEPV2lOtJV2T/2dsb2JhbABbgkdGUlcEsw+YOIFYAQuHSQGBCBZ3hAMBAQEEAQEBKjoHCxACAQgRBAEBCxYHByEGCxQJCAEBBAENBQiIJgMRDcQDDYcPF40fgVUnLQQGAYMvgRwFmW2DWYxfhiWDSWwBgQJC X-IronPort-AV: E=Sophos;i="5.01,775,1400025600"; d="scan'208,217";a="344292690" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2014 23:49:03 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6VNn3Ia024256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 23:49:03 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 18:49:03 -0500 From: "Tissa Senevirathne (tsenevir)" To: "O'Connor, Don" , Tissa Senevirathne , Greg Mirsky Thread-Topic: [nvo3] YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAoWIbcAAAE6agAACU5iwAAR6gcA Date: Thu, 31 Jul 2014 23:49:03 +0000 Message-ID: References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.119] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1Bxmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/Ko6_12zi84QNjDtsGDUFZE9xUFI Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:49:08 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1Bxmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Don I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. Y= ou may have to read in to the details to see the actual differences. From: O'Connor, Don [mailto:don.oconnor@us.fujitsu.com] Sent: Thursday, July 31, 2014 4:32 PM To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@= ietf.org Subject: RE: [nvo3] YANG models for OAM Tissa, Greg, all Metro Ethernet Forum has already standardized Yang Modules for Ethernet Ser= vice OAM Performance Monitoring and Fault Management. Please see MEF 38 and= 39 http://metroethernetforum.org/carrier-ethernet/technical-specifications Regards Don From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne Sent: Thursday, July 31, 2014 5:53 PM To: Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM Greg Yes it is, generic YANG model steup the base framework. It can be extended = to add tools as well as other elements as well technology deviations. Alarm= s etc either be part of this document will be a separate document that spec= ifies them. That is the reason we have designed the model as modular as pos= sible and extensible as possible. Please let us know if any of the parts are not extensible or not modular en= ough. Thanks Tissa On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: Hi Tissa, authors, et. al, I've read documents and would like to clarify scope of these documents. OAM= is not limited to ping and traceroute functions. It even not limited to co= ntinuity check. And in connectionless networks there would not be connectiv= ity verification. And the performance measurement is the big part of OAM as= well as protection coordination, defect alarms, and etc. Hence my question= , is it in plans of the authors to address all of OAM in respective documen= ts? Regards, Greg On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) > wrote: All We have published YANG model for OAM. #1 draft below place the generic fram= ework for OAM, that can be augmented for different technologies. #2 and #3 = are application of the concept to NVO3 and TRILL, 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ Please review and share your comments Thanks Tissa _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1Bxmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Don


I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. You may have to read in to the details= to see the actual differences.

 <= /p>

From: O'Connor= , Don [mailto:don.oconnor@us.fujitsu.com]
Sent: Thursday, July 31, 2014 4:32 PM
To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org;= trill@ietf.org
Subject: RE: [nvo3] YANG models for OAM

 

Tissa, Greg, all=

 

Metro Ethernet Forum has al= ready standardized Yang Modules for Ethernet Service OAM Performance Monito= ring and Fault Management. Please see MEF 38 and 39

 

http://metroethern= etforum.org/carrier-ethernet/technical-specifications=

 

Regards

 

Don

 

From: L2vpn [<= a href=3D"mailto:l2vpn-bounces@ietf.org">mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM

 

Greg=

 

Yes it is, generic YANG model steup the ba= se framework. It can be extended to add tools as well as other elements as = well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. That is the= reason we have designed the model as modular as possible and extensible as= possible.

 

Please let us know if any of the parts are= not extensible or not modular enough.

 

Thanks

Tissa

 

On= Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:<= /o:p>

 

Hi Tissa, autho= rs, et. al,

I've read documents and would like to clarify scope of these document= s. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there= would not be connectivity verification. And the performance measurement is= the big part of OAM as well as protection coordination, defect alarms, and= etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents?

Regards,

Greg=

 

On Tue, Jun 10,= 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

All<= /span>

 

We have publish= ed YANG model for OAM. #1 draft below place the generic framework for OAM, = that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

 

Please review a= nd share your comments

 

Thanks

Tissa

 

 


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

 

 

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1Bxmbrcdx08ciscoc_-- From nobody Thu Jul 31 18:06:50 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7C91A0356; Thu, 31 Jul 2014 18:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 m6o6sUPwW5te; Thu, 31 Jul 2014 18:06:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9D11A0350; Thu, 31 Jul 2014 18:06:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU38814; Fri, 01 Aug 2014 01:06:25 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Aug 2014 02:06:23 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 09:06:17 +0800 From: Qin Wu To: "O'Connor, Don" , Tissa Senevirathne , Greg Mirsky , "Tissa Senevirathne (tsenevir)" Thread-Topic: [nvo3] YANG models for OAM Thread-Index: AQHPrRhFwrWBIAFeCEWqLpizz9QBWJu67tEA Date: Fri, 1 Aug 2014 01:06:16 +0000 Message-ID: References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8458DB09nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/fBtQDXZkOHPmb99cEcsodBSVGig Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 01:06:33 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8458DB09nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB0aGluayBNRUYgbW9yZSBsb29rIGF0IFlhbmcgZGF0YSBtb2R1bGUgZm9yIFkuMTczMSwgSXQg aXMgRXRoZXJuZXQgdGVjaG5vbG9neSBzcGVjaWZpYyBZYW5nIERhdGEgbW9kZWwuDQoNClJlZ2Fy ZHMhDQotUWluDQq3orz+yMs6IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3Jn XSC0+rHtIE8nQ29ubm9yLCBEb24NCreiy83KsbzkOiAyMDE0xOo41MIxyNUgNzozMg0KytW8/sjL OiBUaXNzYSBTZW5ldmlyYXRobmU7IEdyZWcgTWlyc2t5OyBUaXNzYSBTZW5ldmlyYXRobmUgKHRz ZW5ldmlyKQ0Ks63LzTogbDJ2cG5AaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZzsgbnZvM0BpZXRm Lm9yZzsgbmV0bW9kQGlldGYub3JnOyB0cmlsbEBpZXRmLm9yZw0K1vfM4jogUmU6IFtPUFNBV0dd IFtudm8zXSBZQU5HIG1vZGVscyBmb3IgT0FNDQoNClRpc3NhLCBHcmVnLCBhbGwNCg0KTWV0cm8g RXRoZXJuZXQgRm9ydW0gaGFzIGFscmVhZHkgc3RhbmRhcmRpemVkIFlhbmcgTW9kdWxlcyBmb3Ig RXRoZXJuZXQgU2VydmljZSBPQU0gUGVyZm9ybWFuY2UgTW9uaXRvcmluZyBhbmQgRmF1bHQgTWFu YWdlbWVudC4gUGxlYXNlIHNlZSBNRUYgMzggYW5kIDM5DQoNCmh0dHA6Ly9tZXRyb2V0aGVybmV0 Zm9ydW0ub3JnL2NhcnJpZXItZXRoZXJuZXQvdGVjaG5pY2FsLXNwZWNpZmljYXRpb25zDQoNClJl Z2FyZHMNCg0KRG9uDQoNCkZyb206IEwydnBuIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFRpc3NhIFNlbmV2aXJhdGhuZQ0KU2VudDogVGh1cnNkYXksIEp1bHkg MzEsIDIwMTQgNTo1MyBQTQ0KVG86IEdyZWcgTWlyc2t5OyBUaXNzYSBTZW5ldmlyYXRobmUgKHRz ZW5ldmlyKQ0KQ2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IG9wc2F3 Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86 bnZvM0BpZXRmLm9yZz47IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjsg dHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtudm8z XSBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkdyZWcNCg0KWWVzIGl0IGlzLCBnZW5lcmljIFlBTkcg bW9kZWwgc3RldXAgdGhlIGJhc2UgZnJhbWV3b3JrLiBJdCBjYW4gYmUgZXh0ZW5kZWQgdG8gYWRk IHRvb2xzIGFzIHdlbGwgYXMgb3RoZXIgZWxlbWVudHMgYXMgd2VsbCB0ZWNobm9sb2d5IGRldmlh dGlvbnMuIEFsYXJtcyBldGMgZWl0aGVyIGJlIHBhcnQgb2YgdGhpcyBkb2N1bWVudCB3aWxsIGJl IGEgc2VwYXJhdGUgZG9jdW1lbnQgdGhhdCBzcGVjaWZpZXMgdGhlbS4gVGhhdCBpcyB0aGUgcmVh c29uIHdlIGhhdmUgZGVzaWduZWQgdGhlIG1vZGVsIGFzIG1vZHVsYXIgYXMgcG9zc2libGUgYW5k IGV4dGVuc2libGUgYXMgcG9zc2libGUuDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiBhbnkgb2Yg dGhlIHBhcnRzIGFyZSBub3QgZXh0ZW5zaWJsZSBvciBub3QgbW9kdWxhciBlbm91Z2guDQoNClRo YW5rcw0KVGlzc2ENCg0KT24gVGh1cnNkYXksIEp1bHkgMzEsIDIwMTQgMzoxNyBQTSwgR3JlZyBN aXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29t Pj4gd3JvdGU6DQoNCkhpIFRpc3NhLCBhdXRob3JzLCBldC4gYWwsDQpJJ3ZlIHJlYWQgZG9jdW1l bnRzIGFuZCB3b3VsZCBsaWtlIHRvIGNsYXJpZnkgc2NvcGUgb2YgdGhlc2UgZG9jdW1lbnRzLiBP QU0gaXMgbm90IGxpbWl0ZWQgdG8gcGluZyBhbmQgdHJhY2Vyb3V0ZSBmdW5jdGlvbnMuIEl0IGV2 ZW4gbm90IGxpbWl0ZWQgdG8gY29udGludWl0eSBjaGVjay4gQW5kIGluIGNvbm5lY3Rpb25sZXNz IG5ldHdvcmtzIHRoZXJlIHdvdWxkIG5vdCBiZSBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uLiBB bmQgdGhlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IGlzIHRoZSBiaWcgcGFydCBvZiBPQU0gYXMg d2VsbCBhcyBwcm90ZWN0aW9uIGNvb3JkaW5hdGlvbiwgZGVmZWN0IGFsYXJtcywgYW5kIGV0Yy4g SGVuY2UgbXkgcXVlc3Rpb24sIGlzIGl0IGluIHBsYW5zIG9mIHRoZSBhdXRob3JzIHRvIGFkZHJl c3MgYWxsIG9mIE9BTSBpbiByZXNwZWN0aXZlIGRvY3VtZW50cz8NClJlZ2FyZHMsDQpHcmVnDQoN Ck9uIFR1ZSwgSnVuIDEwLCAyMDE0IGF0IDEyOjAzIFBNLCBUaXNzYSBTZW5ldmlyYXRobmUgKHRz ZW5ldmlyKSA8dHNlbmV2aXJAY2lzY28uY29tPG1haWx0bzp0c2VuZXZpckBjaXNjby5jb20+PiB3 cm90ZToNCkFsbA0KDQpXZSBoYXZlIHB1Ymxpc2hlZCBZQU5HIG1vZGVsIGZvciBPQU0uICMxIGRy YWZ0IGJlbG93IHBsYWNlIHRoZSBnZW5lcmljIGZyYW1ld29yayBmb3IgT0FNLCB0aGF0IGNhbiBi ZSBhdWdtZW50ZWQgZm9yIGRpZmZlcmVudCB0ZWNobm9sb2dpZXMuICMyIGFuZCAjMyBhcmUgYXBw bGljYXRpb24gb2YgdGhlIGNvbmNlcHQgdG8gTlZPMyBhbmQgVFJJTEwsDQoNCjEuICAgICAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1uZXRtb2Qtb2FtLw0KMi4g ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFu Zy1vYW0vDQozLiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlz c2EtdHJpbGwteWFuZy1vYW0vDQoNClBsZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29tbWVu dHMNCg0KVGhhbmtzDQpUaXNzYQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm52bzMgbWFpbGluZyBsaXN0DQpudm8zQGlldGYub3JnPG1haWx0 bzpudm8zQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u dm8zDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABA8458DB09nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I think ME= F more look at Yang data module for Y.1731, It is Ethernet technology speci= fic Yang Data model.

 = ;

Regards!

-Qin<= /o:p>

=B7=A2=BC=FE=C8=CB: OPSAWG [mailto:opsawg= -bounces@ietf.org] =B4=FA=B1=ED = O'Connor, Don
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA8=D4=C2<= span lang=3D"EN-US">1=C8=D5 7:32
=CA=D5=BC=FE=C8=CB: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir)
=B3=AD=CB=CD: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ie= tf.org
=D6=F7=CC=E2: Re: [OPSAWG] [nvo3] YANG models for OAM

 

Tissa, Greg,= all

 <= /o:p>

Metro Ethern= et Forum has already standardized Yang Modules for Ethernet Service OAM Per= formance Monitoring and Fault Management. Please see MEF 38 and 39

 <= /o:p>

htt= p://metroethernetforum.org/carrier-ethernet/technical-specifications

 <= /o:p>

Regards=

 <= /o:p>

Don

 <= /o:p>

From: L2vpn [mail= to:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM

 

= Greg

 

Yes it is, generic YANG mod= el steup the base framework. It can be extended to add tools as well as oth= er elements as well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. = That is the reason we have designed the model as modular as possible and ex= tensible as possible.

 

Please let us know if any o= f the parts are not extensible or not modular enough.

 

Thanks

Tissa

 

On Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:<= span lang=3D"EN-US" style=3D"font-family:"Helvetica","sans-s= erif";color:black">

 

= Hi Tissa, authors, et. al,

I've read documents and would like to clarify scope of= these documents. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless = networks there would not be connectivity verification. And the performance = measurement is the big part of OAM as well as protection coordination, defe= ct alarms, and etc. Hence my question, is it in plans of the authors to address all of OAM in respective document= s?

= Regards,

= Greg

 

= On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

= All

=  

= We have published YANG model for OAM. #1 draft below place the generic fram= ework for OAM, that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

=  

=  

= Please review and share your comments

=  

= Thanks

= Tissa

=  

=  


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

=  

 

--_000_B8F9A780D330094D99AF023C5877DABA8458DB09nkgeml501mbschi_-- From nobody Thu Jul 31 18:11:32 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6048A1A034F; Thu, 31 Jul 2014 18:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Jss1tgYigvRg; Thu, 31 Jul 2014 18:11:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57FE1A02BC; Thu, 31 Jul 2014 18:11:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU39017; Fri, 01 Aug 2014 01:11:17 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Aug 2014 02:11:14 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 09:11:11 +0800 From: Qin Wu To: "Tissa Senevirathne (tsenevir)" , "O'Connor, Don" , Tissa Senevirathne , Greg Mirsky Thread-Topic: [nvo3] YANG models for OAM Thread-Index: AQHPrRhFwrWBIAFeCEWqLpizz9QBWJu6U7eAgACcEoA= Date: Fri, 1 Aug 2014 01:11:09 +0000 Message-ID: References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8458DB1Dnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/AK-6mSvlhIpJxnW3z5vAtPOO_7k Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 01:11:26 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8458DB1Dnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RXhhY3RseSwgZGlmZmVyZW50IGxheWVyIG1heSBoYXZlIGRpZmZlcmVudCBhZGRyZXNzaW5nIHNj aGVtZXMuIEJ1dCBJIGFtIHdvbmRlcmluZyB3aGljaCBsYXllciB0aGUgZmxvdyBlbnRyb3BpZXMg YXJlIGFwcGxpZWQ/IEwyLCBMMywgTVBMUyBsYXllcj8NCg0Kt6K8/sjLOiBuZXRtb2QgW21haWx0 bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5l dmlyKQ0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjHI1SA3OjQ5DQrK1bz+yMs6IE8nQ29ubm9yLCBEb247 IFRpc3NhIFNlbmV2aXJhdGhuZTsgR3JlZyBNaXJza3kNCrOty806IGwydnBuQGlldGYub3JnOyBv cHNhd2dAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IG5ldG1vZEBpZXRmLm9yZzsgdHJpbGxAaWV0 Zi5vcmcNCtb3zOI6IFJlOiBbbmV0bW9kXSBbbnZvM10gWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpE b24NCg0KSSBhbSBhd2FyZSBvZiB0aGF0LCBidXQgdGhpcyBpcyBkaWZmZXJlbnQsIE1FRiBZQU5H IG1vZGVsIGlzIHNwZWNpZmljYWxseSBmb3IgRXRoZXJuZXQgYW5kIHN0cnVjdHVyZSBkb2VzIG5v dCBhbGxvdyB0byBicmluZyBkaWZmZXJlbnQgYWRkcmVzc2luZyBzY2hlbWVzIG90aGVyIHRoYW4g TUFDIGFkZHJlc3MuIEFkZGl0aW9uYWxseSB0aGUgcHJvcG9zZWQgc3RhbmRhcmQgYWxsb3cgdG8g YWRkIGZsb3cgZW50cm9waWVzIGFuZCBmYWNpbGl0YXRlIG5lc3RlZCBPQU0gYmV0d2VlbiBkaWZm ZXJlbnQgdGVjaG5vbG9naWVzLiBZb3UgbWF5IGhhdmUgdG8gcmVhZCBpbiB0byB0aGUgZGV0YWls cyB0byBzZWUgdGhlIGFjdHVhbCBkaWZmZXJlbmNlcy4NCg0KRnJvbTogTydDb25ub3IsIERvbiBb bWFpbHRvOmRvbi5vY29ubm9yQHVzLmZ1aml0c3UuY29tXQ0KU2VudDogVGh1cnNkYXksIEp1bHkg MzEsIDIwMTQgNDozMiBQTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZTsgR3JlZyBNaXJza3k7IFRp c3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwy dnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBu dm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPjsgbmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogW252bzNdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KVGlzc2EsIEdyZWcs IGFsbA0KDQpNZXRybyBFdGhlcm5ldCBGb3J1bSBoYXMgYWxyZWFkeSBzdGFuZGFyZGl6ZWQgWWFu ZyBNb2R1bGVzIGZvciBFdGhlcm5ldCBTZXJ2aWNlIE9BTSBQZXJmb3JtYW5jZSBNb25pdG9yaW5n IGFuZCBGYXVsdCBNYW5hZ2VtZW50LiBQbGVhc2Ugc2VlIE1FRiAzOCBhbmQgMzkNCg0KaHR0cDov L21ldHJvZXRoZXJuZXRmb3J1bS5vcmcvY2Fycmllci1ldGhlcm5ldC90ZWNobmljYWwtc3BlY2lm aWNhdGlvbnMNCg0KUmVnYXJkcw0KDQpEb24NCg0KRnJvbTogTDJ2cG4gW21haWx0bzpsMnZwbi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGlzc2EgU2VuZXZpcmF0aG5lDQpTZW50OiBU aHVyc2RheSwgSnVseSAzMSwgMjAxNCA1OjUzIFBNDQpUbzogR3JlZyBNaXJza3k7IFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGll dGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBudm8zQGll dGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW252bzNdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KR3JlZw0KDQpZZXMgaXQgaXMs IGdlbmVyaWMgWUFORyBtb2RlbCBzdGV1cCB0aGUgYmFzZSBmcmFtZXdvcmsuIEl0IGNhbiBiZSBl eHRlbmRlZCB0byBhZGQgdG9vbHMgYXMgd2VsbCBhcyBvdGhlciBlbGVtZW50cyBhcyB3ZWxsIHRl Y2hub2xvZ3kgZGV2aWF0aW9ucy4gQWxhcm1zIGV0YyBlaXRoZXIgYmUgcGFydCBvZiB0aGlzIGRv Y3VtZW50IHdpbGwgYmUgYSBzZXBhcmF0ZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGVtLiBU aGF0IGlzIHRoZSByZWFzb24gd2UgaGF2ZSBkZXNpZ25lZCB0aGUgbW9kZWwgYXMgbW9kdWxhciBh cyBwb3NzaWJsZSBhbmQgZXh0ZW5zaWJsZSBhcyBwb3NzaWJsZS4NCg0KUGxlYXNlIGxldCB1cyBr bm93IGlmIGFueSBvZiB0aGUgcGFydHMgYXJlIG5vdCBleHRlbnNpYmxlIG9yIG5vdCBtb2R1bGFy IGVub3VnaC4NCg0KVGhhbmtzDQpUaXNzYQ0KDQpPbiBUaHVyc2RheSwgSnVseSAzMSwgMjAxNCAz OjE3IFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgVGlzc2EsIGF1dGhvcnMsIGV0LiBhbCwNCkkn dmUgcmVhZCBkb2N1bWVudHMgYW5kIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBzY29wZSBvZiB0aGVz ZSBkb2N1bWVudHMuIE9BTSBpcyBub3QgbGltaXRlZCB0byBwaW5nIGFuZCB0cmFjZXJvdXRlIGZ1 bmN0aW9ucy4gSXQgZXZlbiBub3QgbGltaXRlZCB0byBjb250aW51aXR5IGNoZWNrLiBBbmQgaW4g Y29ubmVjdGlvbmxlc3MgbmV0d29ya3MgdGhlcmUgd291bGQgbm90IGJlIGNvbm5lY3Rpdml0eSB2 ZXJpZmljYXRpb24uIEFuZCB0aGUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgaXMgdGhlIGJpZyBw YXJ0IG9mIE9BTSBhcyB3ZWxsIGFzIHByb3RlY3Rpb24gY29vcmRpbmF0aW9uLCBkZWZlY3QgYWxh cm1zLCBhbmQgZXRjLiBIZW5jZSBteSBxdWVzdGlvbiwgaXMgaXQgaW4gcGxhbnMgb2YgdGhlIGF1 dGhvcnMgdG8gYWRkcmVzcyBhbGwgb2YgT0FNIGluIHJlc3BlY3RpdmUgZG9jdW1lbnRzPw0KUmVn YXJkcywNCkdyZWcNCg0KT24gVHVlLCBKdW4gMTAsIDIwMTQgYXQgMTI6MDMgUE0sIFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpIDx0c2VuZXZpckBjaXNjby5jb208bWFpbHRvOnRzZW5ldmly QGNpc2NvLmNvbT4+IHdyb3RlOg0KQWxsDQoNCldlIGhhdmUgcHVibGlzaGVkIFlBTkcgbW9kZWwg Zm9yIE9BTS4gIzEgZHJhZnQgYmVsb3cgcGxhY2UgdGhlIGdlbmVyaWMgZnJhbWV3b3JrIGZvciBP QU0sIHRoYXQgY2FuIGJlIGF1Z21lbnRlZCBmb3IgZGlmZmVyZW50IHRlY2hub2xvZ2llcy4gIzIg YW5kICMzIGFyZSBhcHBsaWNhdGlvbiBvZiB0aGUgY29uY2VwdCB0byBOVk8zIGFuZCBUUklMTCwN Cg0KMS4gICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW5l dG1vZC1vYW0vDQoyLiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dGlzc2EtbnZvMy15YW5nLW9hbS8NCjMuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC10aXNzYS10cmlsbC15YW5nLW9hbS8NCg0KUGxlYXNlIHJldmlldyBhbmQgc2hh cmUgeW91ciBjb21tZW50cw0KDQpUaGFua3MNClRpc3NhDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbnZvMyBtYWlsaW5nIGxpc3QNCm52bzNA aWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL252bzMNCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA8458DB1Dnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Exactly, d= ifferent layer may have different addressing schemes. But I am wondering wh= ich layer the flow entropies are applied? L2, L3, MPLS layer?

 = ;

=B7=A2=BC=FE=C8=CB: netmod = [mailto:netmod-bounces@ietf.org] =B4=FA= =B1=ED Tissa Senevirathne (tsenevir)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA8=D4=C21=C8=D5 7:49
=CA=D5=BC=FE=C8=CB: O'Connor, Don; Tissa Senevirathne; Greg Mirsky
=B3=AD=CB=CD: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ie= tf.org
=D6=F7=CC=E2: Re: [netmod] [nvo3] YANG models for OAM

 

Don


I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. You may have to read in to the details= to see the actual differences.

 = ;

From: O'Connor, Don [mailto:don.oconnor@us.fujitsu.com]
Sent: Thursday, July 31, 2014 4:32 PM
To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: RE: [nvo3] YANG models for OAM

 

Tissa, Greg,= all

 <= /o:p>

Metro Ethern= et Forum has already standardized Yang Modules for Ethernet Service OAM Per= formance Monitoring and Fault Management. Please see MEF 38 and 39

 <= /o:p>

htt= p://metroethernetforum.org/carrier-ethernet/technical-specifications

 <= /o:p>

Regards=

 <= /o:p>

Don

 <= /o:p>

From: L2vpn [mail= to:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM

 

= Greg

 

Yes it is, generic YANG mod= el steup the base framework. It can be extended to add tools as well as oth= er elements as well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. = That is the reason we have designed the model as modular as possible and ex= tensible as possible.

 

Please let us know if any o= f the parts are not extensible or not modular enough.

 

Thanks

Tissa

 

On Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:<= span lang=3D"EN-US" style=3D"font-family:"Helvetica","sans-s= erif";color:black">

 

= Hi Tissa, authors, et. al,

I've read documents and would like to clarify scope of= these documents. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless = networks there would not be connectivity verification. And the performance = measurement is the big part of OAM as well as protection coordination, defe= ct alarms, and etc. Hence my question, is it in plans of the authors to address all of OAM in respective document= s?

= Regards,

= Greg

 

= On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

= All

=  

= We have published YANG model for OAM. #1 draft below place the generic fram= ework for OAM, that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

=  

=  

= Please review and share your comments

=  

= Thanks

= Tissa

=  

=  


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

=  

 

--_000_B8F9A780D330094D99AF023C5877DABA8458DB1Dnkgeml501mbschi_-- From nobody Thu Jul 31 18:42:33 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9021A0358; Thu, 31 Jul 2014 18:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 loqNCqhYCug8; Thu, 31 Jul 2014 18:42:28 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821701A035F; Thu, 31 Jul 2014 18:42:27 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so5522852vcb.22 for ; Thu, 31 Jul 2014 18:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lRR2kV8rhMHbMTe93Q6AG6IuR2LmqzC8cOYPUx5AKQc=; b=hF/leVOF2JZIQz9gMQDIHAFVyXRlKsj7dtogxSaXiH8Vl1aOChuRBvThe5DQWutmpW xysigIINz547WS0FDfwOnBgetYTPiwJMO4QagpFKmusDHz1GIBflOqsN1eex9pg6yk8P +Y905XCt3bP8tjo3parBP/WUxQ3sSgt/7u2cSvpV9cdwY2lyClxGgVJipM4UV6RU7hFY h+GflgNnYPdst5l6YmCIwqh3k2xJepj5jMMl7dmHNYm4trwxHNcAg8YxpOlv73LUO4Xy G0j8Tpb0M/F99u6Tp+VCHRWoGdOAKmWd14Y6Egp4EOigi98izBScmb9fuLYjvR27Bq/5 zCcA== MIME-Version: 1.0 X-Received: by 10.220.116.196 with SMTP id n4mr2752633vcq.6.1406857346700; Thu, 31 Jul 2014 18:42:26 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 31 Jul 2014 18:42:26 -0700 (PDT) In-Reply-To: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> Date: Thu, 31 Jul 2014 18:42:26 -0700 Message-ID: From: Greg Mirsky To: Tissa Senevirathne Content-Type: multipart/alternative; boundary=047d7b34354c665c7504ff87809e Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/slpBQoCCyisyrB0tvkUcrEuxhqA Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , "Tissa Senevirathne \(tsenevir\)" , "opsawg@ietf.org" Subject: Re: [nvo3] YANG models for OAM X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 01:42:30 -0000 --047d7b34354c665c7504ff87809e Content-Type: text/plain; charset=UTF-8 Hi Tissa, I feel that clear definition of the scope of work is important. From reading the documents, my impression, is that on-demand OAM tools that support detection and localization of Loss of Continuity defect are in scope while the rest of OAM is for further study. I think that it would benefit the documents and discussion if scope be firmly set. Regards, Greg On Thu, Jul 31, 2014 at 3:53 PM, Tissa Senevirathne < tissasenevirathne@yahoo.com> wrote: > Greg > > Yes it is, generic YANG model steup the base framework. It can be extended > to add tools as well as other elements as well technology deviations. > Alarms etc either be part of this document will be a separate document that > specifies them. That is the reason we have designed the model as modular as > possible and extensible as possible. > > Please let us know if any of the parts are not extensible or not modular > enough. > > Thanks > Tissa > > > On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: > > > Hi Tissa, authors, et. al, > I've read documents and would like to clarify scope of these documents. > OAM is not limited to ping and traceroute functions. It even not limited to > continuity check. And in connectionless networks there would not be > connectivity verification. And the performance measurement is the big part > of OAM as well as protection coordination, defect alarms, and etc. Hence my > question, is it in plans of the authors to address all of OAM in respective > documents? > > Regards, > Greg > > > On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) < > tsenevir@cisco.com> wrote: > > All > > We have published YANG model for OAM. #1 draft below place the generic > framework for OAM, that can be augmented for different technologies. #2 and > #3 are application of the concept to NVO3 and TRILL, > > 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ > 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ > 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ > > Please review and share your comments > > Thanks > Tissa > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > --047d7b34354c665c7504ff87809e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tissa,
I feel that clear defini= tion of the scope of work is important. From reading the documents, my impr= ession, is that on-demand OAM tools that support detection and localization= of Loss of Continuity defect are in scope while the rest of OAM is for fur= ther study. I think that it would benefit the documents and discussion if s= cope be firmly set.

Regards,
Greg

On Thu, Jul 31, 2014 at 3:53 PM, Tissa Senevir= athne <tissasenevirathne@yahoo.com> wrote:
Greg

= Yes it is, generic YANG model steup the base framework. It can be extended = to add tools as well as other elements as well technology deviations. Alarm= s etc either be part of this document will be a separate document that spec= ifies them. That is the reason we have designed the model as modular as pos= sible and extensible as possible.

Please let us know if any of the parts are not extensible or not modular en= ough.

Thanks
Tissa


On Thursday, July 31, 2014 3:17 PM, Greg Mirsky <= ;gregimirsky@gma= il.com> wrote:


Hi= Tissa, authors, et. al,
I've read documents an= d would like to clarify scope of these documents. OAM is not limited to pin= g and traceroute functions. It even not limited to continuity check. And in= connectionless networks there would not be connectivity verification. And the performance= measurement is the big part of OAM as well as protection coordination, def= ect alarms, and etc. Hence my question, is it in plans of the authors to ad= dress all of OAM in respective documents?

Regards,
Greg


On Tue, Jun 10,= 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:
All
=C2=A0
We have published YANG model for OAM. #1 draft below place the generic= framework for OAM, that can be augmented for different technologies. #2 an= d #3 are application of the concept to NVO3 and TRILL,
=C2=A0
3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 http://= datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/
=C2=A0
Please review and share your comments
=C2=A0
Thanks
=
Tissa
=C2=A0
=C2=A0

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


=

=

--047d7b34354c665c7504ff87809e-- From nobody Thu Jul 31 23:08:30 2014 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2413E1A0409; Thu, 31 Jul 2014 23:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 JsDT0p8H9bvH; Thu, 31 Jul 2014 23:08:25 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F351A028E; Thu, 31 Jul 2014 23:08:24 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E80AD2AA0F; Fri, 1 Aug 2014 06:08:18 +0000 (GMT) Date: Thu, 31 Jul 2014 23:08:28 -0700 From: Marc Binderberger To: Dino Farinacci , Eric Gray Message-ID: <20140731230828372641.3d067333@sniff.de> In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/1IlHRtiIr0MceN9xBV64mb3vsAs Cc: David Melman , "nvo3@ietf.org" , Larry Kreeger , LISP mailing list list , Tom Herbert Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 06:08:28 -0000 Hello Dino, always interesting, different people interpret differently. You seem to talk about controlling where the OAM data flows. I don't think this is what Eric means. As long as a flow is defined in the traditional 3- or 5-tuple way from the IP/UDP packet and as long as every router is mapping the same flow onto the same ECMP egress interface we are fine. The details - the exact algorithm, if the algorithm uses the router-id as an additional hash or whatever else - don't matter. The OAM packet would use the same IP/UDP header as the data packet it's supervising. And the receiver processes OAM packets as "OAM" because of the flag set. > One needs to argue if you really need the granuarlity for the complexity > that will needed to get this partially correct. > Well I think LISP RLOC-probing is good enough, but I am biased. ;-) you are "rich" by having an additional control plane UDP port ;-) I don't see much complexity although I agree that just knowing if the RLOC is alive and ping-able may be enough in many cases. If we can get more like in-band OAM - why not? > If an ITR sends a packet the ETR's address, the middle boxes do not know if > it is a control-packet versus a data-packet. true but e.g. for LISP, while the middle box may have no idea what 4341 and 4342 as udp ports mean, it could still calculate a different hash bucket for ECMP due to the different UDP port. Hmm, my statement is so trivial - I assume you want to say something different with your reply? > I am trying to avoid problems. Seems like things are being over-engineered. > Again. I would say the echo nonce in RFC6830 is not fundamentally different from OAM. The N+E flags trigger some activity on the receiver, similar to OAM. > P.S. Sorry I keep being negative. And if one person says shut up, I'll stop > posting. well, everyone is entitled to his/her opinion and to voice it in his/her personal style. You have a point as I was a bit upset myself about this draft: there is likely more about it, otherwise why would we discuss yet-another-8-byte-header? Fabio offered the simplification the new header offers but for a while we will have 2-3 slightly different headers that need active support in the code or hardware. Actually in terms of code - be it C or Verilog - I'm not sure there is any simplification ever over VxLAN + LISP. But at least the situation of having both VxLAN and LISP can be simplified by having a common umbrella and one common discussion. Personally I think VxLAN-gpe is how the VxLAN/LISP header could have looked like from the start (hindsight is great, I know) and I don't have a technical problem with the draft itself. What is missing is enough context to discuss it. E.g. I'm still not sure why there is a P flag, if for a hard technical reason or for the aesthetics that every field is controlled by a turn-on flag ;-) So I encourage and kindly ask the authors to provide more of this context in the next draft version. Regards, Marc On Thu, 31 Jul 2014 16:16:53 -0700, Dino Farinacci wrote: >> Dino, >> >> Would you re-phrase your response? I am having some trouble parsing it, >> so >> I must be missing something. >> >> First, I think (when you said "... sent from any pair of ports ...") you >> meant to >> say "... sent with any pair of ports ..." - but this is a guess. > > Yes "with" is a better way of stating it. > >> As for making OAM messages traverse the exact same path as data, this is >> what OAM is expected to do. In essence, if data follows a path that >> involves > > Good luck. I do not how you will be able to control each ECMP path at each > path across different vendors as well as the same vendor with different > hashing algorithms. > > One needs to argue if you really need the granuarlity for the complexity > that will needed to get this partially correct. > >> a non-zero number of gates, while OAM does not, the successful delivery of >> OAM is only an approximate indication of the data-path integrity. Any H/W >> that data has to go through, and OAM does not go through, could fail and we >> would see an OAM indication of a valid path through which data either would >> not go, or would be diverted in some unexpected way. > > Well I think LISP RLOC-probing is good enough, but I am biased. ;-) > >> Ordinarily, this should not be a problem for the hardware, as (ordinarily) >> the >> OAM is indistinguishable from data. The hardware works no harder to push >> OAM than it would to push an equivalent amount of data. > > If an ITR sends a packet the ETR's address, the middle boxes do not know if > it is a control-packet versus a data-packet. > >> So, what is the problem again? > > I am trying to avoid problems. Seems like things are being over-engineered. > Again. > > Dino > > P.S. Sorry I keep being negative. And if one person says shut up, I'll stop > posting. > >> >> -- >> Eric >> >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci >> Sent: Wednesday, July 30, 2014 9:13 PM >> To: Larry Kreeger >> Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list list; >> nvo3@ietf.org >> Subject: Re: [nvo3] Comments on >> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >> >>> I'm assuming that routers and switches will be multipathing based on >>> the UDP port numbers, so I would expect different destination UDP >>> ports to take different equal cost paths. >> >> Well if OAM is going to be effective, messages need to be sent from any >> pair of ports that yield 0 through N modulus so multiple paths can be >> determined. So it doesn't matter with the port number values you use, >> those control packets will be ECMPed as well. >> >> If you are also inferring that you want the OAM packets to go through the >> same data-path of each device on the path, then you will have to put TLVs >> in the data path, which is traditionally not prudent. See my Puneet >> reference from previous email. >> >> Dino >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >