[180404] in North American Network Operators' Group
Re: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Tue Jun 2 00:44:14 2015
X-Original-To: nanog@nanog.org
Date: Mon, 1 Jun 2015 21:44:11 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
In-Reply-To: <CAL9jLab15NuTY_szwsHnvBB6Fs=Hf0KQSg5hm18K1eT3vaZgaw@mail.gmail.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--llIrKcgUOe3dCx0c
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon 2015-Jun-01 13:20:57 -0400, Christopher Morrow <morrowc.lists@gmail.=
com> wrote:
>On Mon, Jun 1, 2015 at 12:21 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
>> 2. Just do it properly the first time around.
>>
>> I would opt for #2.
>
>sure, so would everyone... but they didn't so... what gets you enough
>there to help customers and also doesn't required a forklift of your
>running operation?
Sorry; I worded this poorly. Obviously they didn't go dual stack right at=
=20
the outset. Options #1 and #2 I listed were done from the perspective that=
=20
it's currently a v4-only environment, and some measure of work has to be=20
done to get it to have v6 capability of *some* form.
I'm working with the (soon to be not) unspoken assumption of a future state=
=20
of the platform where we've "v6'd all the things", checking off all of the=
=20
boxes in your original message on this; paraphrased:
- Every VM has a v6 address
- VMs can talk to backend services (including on your prem) over v6
- VM/system admin interfaces are reachable over v6
- You can serve up v6-accessible services from your VM(s)
If my (previously unspoken) assumption of a fully v6-capable future state=
=20
of the platform holds, I'm saying that going with a proxy-type solution as=
=20
an interim stopgap solution carries a whole bunch of additional=20
labor/operational cost. Implementing either option #1 or option #2 carries=
=20
some combination of cost from hardware, software, and elbow grease, with=20
values of 0 to $bigint in each category. To be fair: some of the=20
additional elbow grease cost from option #1 is externalized from the hoster=
=20
to either customers and/or the developers of the software stacks used by=20
customers. That notwithstanding: if you're going to need to do #2 at some=
=20
point anyway, why not just skip #1 and put your energy into #2 to start=20
with?
To be honest: I don't think we are diametrically opposed on this. Backing=
=20
up a bit:
>Would AWS (or any other cloud provider that's not currently up on the
>v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service
>(perhaps not just http/s services even?) be enough to relieve some of
>the pressure on other parties and move the ball forward meaningfully
>enough for the cloud providers and their customers?
Relieve some pressure and possibly generate at least *some* forward=20
momentum? Sure. And AWS is obviously free to do as they see fit. I think=
=20
a lot of folks in this discussion are just tired of seeing half measures=20
that expend a bunch of resources to delay the inevitable and push us=20
further into CGN hell when those resources could rather have been allocated=
=20
to a proper dual-stack or v6-only solution.
--
Hugo
--llIrKcgUOe3dCx0c
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJVbTSbAAoJEJqxD/2xeDE+CtoP/3Y7+NznhKLIr5je7sKy9m7B
xkPdcliLy3uKVfrHENt0JwHar1QQSax/DuEFzPFlN8VUbCBDJKe1nzDwfH9HG9Vw
JN1CIzvi0KVdwSSjCgjb+LoklCrdYcLdOcW2EjKWakyS/8Nxw6rSdsyXXrMnLNJA
2NuOWluQHaTtSvpw/psk9NsNXtHiGV8R8pQ8rIpNmkEMZb3M7B2BElwRW1p9DW1s
nHfA2qAcQY5QmyXLbFX0FNFVYVSwyxQNIcvaCQWl5E5NVYV0bxCiqKeCwwbi2lA+
dQJOnXLakgqMtJeBDPi5SxaJWL+W20OXdiAfcXHFnZGrcfag+Qb68SPO/2fsZFKM
b9XI+8TFPUEUFFOCpm8N9Daw/ILdnqXATv1fSZR3o6LA+reTgLV0ugsD/4LKhoGs
Gaz1ROjQVeSSu6n7Thad62pvLtMU5w65oxdveGQX8uOMdKmYOUNXRB6seOJ4q3x4
WiGTUuQlmloBSWYD75BXfPr3HSGIFPMiB4ZahetkhZJiwAy6bgJyGJJGs04Z5BAT
Dvnsx8LgDpDWu2rdZA3pZI7AJrLGgcV0b9SI4UiWtyQaZmUiBen16/EGDn14dnvl
uF6a2WHUlJZ8USVNYyp+sF75ajbgH8a1eP+l4wRJW1ls8KKVAwnL3Val70iSiSJa
SC5331nvO+5JPFCtuGD8
=+Xse
-----END PGP SIGNATURE-----
--llIrKcgUOe3dCx0c--
