Re: [v6ops] State of play as of today

Tom Herbert <tom@herbertland.com> Thu, 01 October 2015 23:59 UTC

Return-Path: <tom@herbertland.com>
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 208DA1A90A3 for <v6ops@ietfa.amsl.com>; Thu, 1 Oct 2015 16:59:47 -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=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 nSvIC3SzfTBN for <v6ops@ietfa.amsl.com>; Thu, 1 Oct 2015 16:59:45 -0700 (PDT)
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7611A90A5 for <v6ops@ietf.org>; Thu, 1 Oct 2015 16:59:45 -0700 (PDT)
Received: by igbkq10 with SMTP id kq10so7661298igb.0 for <v6ops@ietf.org>; Thu, 01 Oct 2015 16:59:45 -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:cc:content-type :content-transfer-encoding; bh=ANhthjssVpR2Gv0PsoDhhxY8GPsCo/gpNaV/WVlAo78=; b=R8afbjtqGV1fjW3pBRQ4dJ8rmBSgfR5E1V9GKXCVgjxF0SGRKkB/GtGILHnPWENpOC 5o8qeEGAUs//vCCX6R50yzr6vTMWbp0rMWGyXlWcnhcPVjFYbKCUM6LoPka+76JcVVF9 5gJthUURJ/l3etTSXTzs9HZ/AQiLJ5hmcGuDDFkbov95bZJC1DEc2WUpS5JccS4cWZcc yUoF4gmcIR0NHtZaDONMwREoOe/xdLsCUMx4Ill+PYTTLK6uobqM7K/Ep1jsv92x7Dg4 odfdyNLCsXT/7JgsbnDr9l388fIlr/17j8er8mcQX0QfxkoaI/QS8OPBbJg2APwpGu0J swQg==
X-Gm-Message-State: ALoCoQkM+tZkxxxzrR2kMRPkgEpJyj7oa6/vRNiotuysmfiiZTkupFCgTb9lnGKa6rtN1CGiiV5j
MIME-Version: 1.0
X-Received: by 10.50.134.231 with SMTP id pn7mr1545210igb.89.1443743984990; Thu, 01 Oct 2015 16:59:44 -0700 (PDT)
Received: by 10.107.128.94 with HTTP; Thu, 1 Oct 2015 16:59:44 -0700 (PDT)
In-Reply-To: <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com>
References: <71893E8D-913C-4F12-B159-4E522861A0E4@cisco.com> <75B6FA9F576969419E42BECB86CB1B891690C2BE@xmb-rcd-x06.cisco.com> <41497FF1-E7F3-4A4C-8434-D9BD54E152B6@cisco.com>
Date: Thu, 01 Oct 2015 16:59:44 -0700
Message-ID: <CALx6S36=SPqxzB4NpCOR7tZqSiHnAwvGU0eUr7jPZQK83sCG5Q@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/6_atjyLM3jT3fHyYSSx426vPm4U>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] State of play as of today
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 01 Oct 2015 23:59:47 -0000

>>> I do have a proposal from Tom Herbert (formerly Google, now Facebook) to discuss https://tools.ietf.org/html/draft-herbert-nvo3-ila. This is interesting in the context of allocation of a /64 to a host in a >data center. He tells me that there are a few changes (notably a routable interior address) in a version he is about to post, and that Facebook plans some "canary" deployments to test the concepts. I >tend to think it would be an interesting discussion, but have not heard from the working group.
>>
>> If Tom could please update the document with an email that does not bounce back when people contact him for his submission, I'd appreciate it.
>
Sorry about that, I'll update the draft soon.

> He seems to be using tom@herbertland.com
>
Yes.

>>  Certainly, this work could be discussed including the fact whether the consensus is to remain within the 64-bit boundary between the interface-id vs. not for any IPv6 addressing.
>>
>> Other comments:
>>
>> In section5.1.2 , the document says "Since migrations should be relatively rare events,".   If migration is a rare event, is it worth solving the task move problem?  Why not stay with "not to migrate" until the task runs to completion and not work on any ILA?
>>
Rare is relative here, in a large data center we could be migrating
hundreds of jobs per second. There are also instances where we need to
a mass migration like when we need to bring down a cluster for repair.
The salient property is that the cost of adding the ability to migrate
is near zero when tasks that are not migrating.

>> The WG  and the author could decide if the document serves the purpose for ILA and task move but keeps away from tenant separation because the security  in section 5.2 and its 3rd paragraph which ends in "not considered a significant risk" is questionable.   I suspect security will take lot more effort.

It's not a significant security risk in the sense that all tenants are
already part of the same entity. In a cloud application with third
party untrusting tenants then ILA would probably not offer adequate
security (although I would point out that this is no worse security
than with VXLAN).

Tom

>>
>> Thanks,
>>
>> Hemant
>