Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap
Dino Farinacci <farinacci@gmail.com> Sun, 16 March 2014 19:59 UTC
Return-Path: <farinacci@gmail.com>
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 0A8BA1A030D for <nvo3@ietfa.amsl.com>; Sun, 16 Mar 2014 12:59: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 Jn4hCiB_XKaM for <nvo3@ietfa.amsl.com>; Sun, 16 Mar 2014 12:59:27 -0700 (PDT)
Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFC01A0223 for <nvo3@ietf.org>; Sun, 16 Mar 2014 12:59:27 -0700 (PDT)
Received: by mail-pb0-f43.google.com with SMTP id um1so4785290pbc.16 for <nvo3@ietf.org>; Sun, 16 Mar 2014 12:59:19 -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=5VXr3RNQOsGF7R/sWa5DFoywYdnJ/g1yhPD+LcOfSL8=; b=NsKH4gqHqQHoJ+F+41h5Q6TFuBFDBMGL9YO9rRZpNmr/NzKfShKkRGks49PF2iIGHA mrLdF0j3J7vj7kLnkr+FsUmo/IuGWZg+6lzQt4ALBCTSNvSQgwyg0u5tBdf85FPvrvl4 MbTtJUwuoco66uurKr35OEO37IKeW0WsMpVI5wNVRjTIDfIgotuGHTuLU3q9St/wW0AF muGF7/rPPjzLBAk1sgfIXjgXDwrmnkReKuuQSfNpIr7V+y27QiLQN/v1ZPnW6yIVCFsW hNiTGsJub47PEX2E8BLO0hOLOUhEJHsrLbJvDpmaZt7E/71x4uE9OvsuOBrHgG1b8TIl tLpw==
X-Received: by 10.66.9.41 with SMTP id w9mr21283118paa.39.1394999959658; Sun, 16 Mar 2014 12:59:19 -0700 (PDT)
Received: from [192.168.1.17] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id sh5sm36721330pbc.21.2014.03.16.12.59.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 12:59:18 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Dino Farinacci <farinacci@gmail.com>
X-Mailer: iPhone Mail (11D167)
In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C39241E6A@eusaamb105.ericsson.se>
Date: Sun, 16 Mar 2014 12:59:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA034207-A9BB-40BB-B052-6CBDAD8D8809@gmail.com>
References: <2691CE0099834E4A9C5044EEC662BB9D45354603@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632A2BAD1@eusaamb107.ericsson.se> <026b01cf4108$9e58b070$db0a1150$@riw.us> <F10451DB-7C6E-4ED1-ABC0-37E8B3CD80FD@gmail.com> <5C5D3148-261D-4428-AC6B-AAAD4436D048@lucidvision.com> <E6C17D2345AC7A45B7D054D407AA205C39241E6A@eusaamb105.ericsson.se>
To: David Allan I <david.i.allan@ericsson.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/8yasWAMqXtV7g3DJQYRpEdk-bJw
Cc: Thomas D Nadeau <tnadeau@lucidvision.com>, "<draft-gross-geneve@tools.ietf.org>" <draft-gross-geneve@tools.ietf.org>, "<nvo3@ietf.org>" <nvo3@ietf.org>, Lucy yong <lucy.yong@huawei.com>, Russ White <russw@riw.us>, Eric Gray <eric.gray@ericsson.com>
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Mar 2014 19:59:30 -0000
Maybe the power struggle should not focus so much on WHAT is delivered but HOW it is developed and delivered. A thought offered to me recently from a close friend. Dino > On Mar 16, 2014, at 12:56 PM, David Allan I <david.i.allan@ericsson.com> wrote: > > The actual examples cited are artifacts of an industry power structure that may not apply in this case, as far as past performance predicting future outcomes.... > > D > > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Thomas D Nadeau > Sent: Sunday, March 16, 2014 9:10 AM > To: Dino Farinacci > Cc: Russ White; <draft-gross-geneve@tools.ietf.org>; <nvo3@ietf.org>; Lucy yong; Eric Gray > Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap > > This road is littered with many examples in recent history of new alternatives presenting the dream of "a new encap/protocol will fix everything" such as crldp, PBT and PBB-TE. let's not make this mistake if we can help it... > > Tom > > >> On Mar 16, 2014, at 11:48, Dino Farinacci <farinacci@gmail.com> wrote: >> >> Decades of experience tells us what Russ says below. Those who choose to ignore are bound to repeat ... >> >> Dino >> >>> On Mar 16, 2014, at 4:12 AM, "Russ White" <russw@riw.us> wrote: >>> >>> >>>> 3) create a new encapsulation that meets requirements - and find out >>>> that the >>>> industry doesn't entirely switch over to the new (read untried >>>> and >>> possibly >>>> immature) encapsulation, existing deployed alternatives are >>> documented >>>> in >>>> some (possibly non-standard) way and we incur the costs >>>> associated >>> with >>>> living with three alternatives additional encapsulations until >>>> such >>> time (if >>>> ever) >>>> when the DCN industry settles on fewer (possibly as few as one) >>> choices, >>>> and >>>> we move on. >>> >>> This is, in fact, the most likely result... Vendors would need to >>> remove support for the old encaps over time, which isn't going to >>> happen so long as someone is actually using them, which means support >>> will still be in code, which means new people will start using them, which means... >>> >>> There is also a cost in security when it comes to defining new encap >>> types we often don't consider -- it's one more tunnel type that needs >>> to be accounted for by middle boxes, network hardening routines, etc. >>> For every new encap we create, we also create a lot of work in the >>> security world in tracking vulnerabilities, understanding the semantics of the protocol, etc. >>> >>> The right answer, IMHO, is to modify, rather than creating a new encap. >>> >>> :-) >>> >>> Russ >>> >>> _______________________________________________ >>> 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] enhancing VXLAN/NVGRE vs creating an new e… Lucy yong
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Anton Ivanov (antivano)
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Lucy yong
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Anton Ivanov (antivano)
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Sam Aldrin
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Eric Gray
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Lucy yong
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Shahram Davari
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Tom Herbert
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Lucy yong
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Shahram Davari
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Thomas Nadeau
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Lucy yong
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Russ White
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Dino Farinacci
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Thomas D Nadeau
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… David Allan I
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Dino Farinacci
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Thomas D Nadeau
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Tom Herbert
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Shahram Davari
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Tom Herbert
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Anton Ivanov (antivano)
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… AshwoodsmithPeter
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Zhou, Han
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Dino Farinacci
- Re: [nvo3] enhancing VXLAN/NVGRE vs creating an n… Greg Mirsky