IETF Logo Mail Archive

Re: [v6ops] Please review the No IPv4 draft

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 29 April 2014 05:29 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E01A884C for <v6ops@ietfa.amsl.com>; Mon, 28 Apr 2014 22:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.602
X-Spam-Level:
X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, 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 wmB5M9_DDPsW for <v6ops@ietfa.amsl.com>; Mon, 28 Apr 2014 22:29:36 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id E534D1A8843 for <v6ops@ietf.org>; Mon, 28 Apr 2014 22:29:35 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id B5013A2; Tue, 29 Apr 2014 07:29:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398749373; bh=W7ttrkbcY+bdSTETEHDAVg1oultNuPFahhD4Qx9iAXU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=LytF9tEAJqD+h1FvOjjBcX4vMl6dxp8tIBwVZgYEC3PN+OOeNWyMDO73M206OtL2f xGrxn0qmTy1fJmAvVKtX/8qVjI0TApfPhj5cNQ2E4nU2g801TtHOFwhRq6F+VcL5jp fdbT4+4p3q262t/xfIU+0VxhvLd7q1NZH0NxHDyU=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A9CBDA1; Tue, 29 Apr 2014 07:29:33 +0200 (CEST)
Date: Tue, 29 Apr 2014 07:29:33 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Nick Hilliard <nick@foobar.org>
In-Reply-To: <535F3624.4020801@foobar.org>
Message-ID: <alpine.DEB.2.02.1404290726011.29282@uplift.swm.pp.se>
References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <m24n1l8i1a.wl%Niall.oReilly@ucd.ie> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <m238gxpgrt.wl%Niall.oReilly@ucd.ie> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <m2mwf59uht.wl%Niall.oReilly@ucd.ie> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_x3g2b9OhIbH-7QMVldpIiGFY1E
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Please review the No IPv4 draft
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Apr 2014 05:29:38 -0000

On Tue, 29 Apr 2014, Nick Hilliard wrote:

> One reason specific to virtualised environments is that commercial 
> services require high availability with fast failover to alternative 
> gateways.  This means VRRP (or your favourite first-hop redundancy 
> protocol) because fast failover with RA isn't feasible.  You cannot run 
> a vrrp instance per customer because that doesn't scale.  That means 
> putting tenants in a shared domain so you can share the same gateway for 
> multiple customers.

Then demand that the virtualised environment vendors do what the access 
switch vendors have done for a long time, implement either private vlan or 
SAVI type functionality.

... or put L3 routing so far out into the network that VRRP actually does 
scale, or use virtualised machines to do the VRRP so you can split it up 
between a lot of CPUs.

It's not like this is unsolvable.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email