Re: [sami] Welcome to SAMI and something you may like to know.

Melinda Shore <melinda.shore@gmail.com> Thu, 18 August 2011 00:50 UTC

Return-Path: <melinda.shore@gmail.com>
X-Original-To: sami@ietfa.amsl.com
Delivered-To: sami@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4600E11E8095 for <sami@ietfa.amsl.com>; Wed, 17 Aug 2011 17:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3K+qhfTG6Ri for <sami@ietfa.amsl.com>; Wed, 17 Aug 2011 17:50:36 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C665E21F8AF7 for <sami@ietf.org>; Wed, 17 Aug 2011 17:50:36 -0700 (PDT)
Received: by pzk33 with SMTP id 33so3279586pzk.18 for <sami@ietf.org>; Wed, 17 Aug 2011 17:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7wViil3NAZ9LVprX3rvfxVCaxmrrHnX2atWo7ckLgQA=; b=NmTGHVq4w65q11FGj0B7Vw0SvVp1eb1xc5sk1UK92WZnIAnsJdwHxYeA665ANlPLWT OJj/aGN5q9ZlGvfuGnFxo7jrM6FQYcuME013P+415WPmUrNrs2TQZIQe8ilLE8O+K8do 6fzPBbE63ljuceSjTXNiK+0uTcF3T9f+e7l3k=
Received: by 10.143.69.12 with SMTP id w12mr49609wfk.298.1313628689240; Wed, 17 Aug 2011 17:51:29 -0700 (PDT)
Received: from [137.229.12.236] (drake.swits.alaska.edu [137.229.12.236]) by mx.google.com with ESMTPS id n3sm1030464pbi.21.2011.08.17.17.51.27 (version=SSLv3 cipher=OTHER); Wed, 17 Aug 2011 17:51:28 -0700 (PDT)
Message-ID: <4E4C6214.3010800@gmail.com>
Date: Wed, 17 Aug 2011 16:51:32 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com>
In-Reply-To: <006001cc5cbb$de6c48e0$9b44daa0$@com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Cc: sami@ietf.org
Subject: Re: [sami] Welcome to SAMI and something you may like to know.
X-BeenThere: sami@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: State Migration <sami.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sami>, <mailto:sami-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sami>
List-Post: <mailto:sami@ietf.org>
List-Help: <mailto:sami-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sami>, <mailto:sami-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2011 00:50:37 -0000

On 08/17/2011 12:58 AM, Yingjie Gu(yingjie) wrote:
> So,pehhaps we can define the scope as such:A layer 2 subnet with good enough
> performance which makes the hot migration successful."

I think it would be worthwhile, should this work go forward, to
describe what happens (or what should happen) if the failover
is unsuccessful - things like at what point state transfer happens.
It seems to me that there's a pretty clear decision point around
whether or not you wait until the failover is complete and
successful (can you know if it's successful before it's complete?)
before transferring middlebox state, and I definitely would
not like to see that dismissed as out-of-scope before any work
is even chartered.

I'd also stay away from "good enough performance" - not really
sure what that means in a technical context.

Scope would be something along the lines of:

    The work will cover transfer of associated middlebox state [and
    i'd probably enumerate examples - probably includes firewall
    pinholes, probably does not include layer 3 routing] needed to
    maintain existing network flows as a network services fail
    over to a hot standby.  Doing the hokey-pokey is out-of-scope.

That needs a lot of work and it would need definition of terms
like "hot standby" and "middlebox," etc., but it describes what
will be included in the work and what will not.

Melinda