Re: [sami] Trying to figure out where we are

Thomas Narten <narten@us.ibm.com> Thu, 25 August 2011 13:11 UTC

Return-Path: <narten@us.ibm.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 CDC6121F87FC for <sami@ietfa.amsl.com>; Thu, 25 Aug 2011 06:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.467
X-Spam-Level:
X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 6reUVfa0mO97 for <sami@ietfa.amsl.com>; Thu, 25 Aug 2011 06:11:18 -0700 (PDT)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 0409021F8783 for <sami@ietf.org>; Thu, 25 Aug 2011 06:11:17 -0700 (PDT)
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7PCwiko014540 for <sami@ietf.org>; Thu, 25 Aug 2011 08:58:44 -0400
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7PDBEDt177196 for <sami@ietf.org>; Thu, 25 Aug 2011 09:11:14 -0400
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7P7BALj018886 for <sami@ietf.org>; Thu, 25 Aug 2011 01:11:12 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-65-200-237.mts.ibm.com [9.65.200.237]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7P7B97e018786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2011 01:11:09 -0600
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7PDB8e1019968; Thu, 25 Aug 2011 09:11:09 -0400
Message-Id: <201108251311.p7PDB8e1019968@cichlid.raleigh.ibm.com>
To: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
In-reply-to: <005e01cc6325$c3bceca0$4b36c5e0$@com>
References: <CA77E180.13DD5%bschlies@cisco.com> <4E541EE7.1080605@gmail.com> <000c01cc6220$3b18fa70$b14aef50$@com> <201108241403546051654@chinamobile.com> <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com> <005e01cc6325$c3bceca0$4b36c5e0$@com>
Comments: In-reply-to "Yingjie Gu(yingjie)" <guyingjie@huawei.com> message dated "Thu, 25 Aug 2011 20:51:52 +0800."
Date: Thu, 25 Aug 2011 09:11:08 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: 'Melinda Shore' <melinda.shore@gmail.com>, sami@ietf.org, 'zhangyunfei' <zhangyunfei@chinamobile.com>
Subject: Re: [sami] Trying to figure out where we are
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, 25 Aug 2011 13:11:19 -0000

"Yingjie Gu(yingjie)" <guyingjie@huawei.com> writes:

> In previous mail discussion, there are questions on why should VM be
> migrated.

I think we should take it as a given that VMs move around. People do
that today, we all see the value.

> And also, in the side meeting at Quebec, people want to learn the use case
> from real scenario.

Yes. looking at specific scenarios allows us to ask the question of
whether the scenario is realistic and corresponds to what operators
actual do today (or want to do), or whether it is just a theoretical
problem (in which case it's very questionable whether the IETF should
do work.)

> I guess Yunfei's use case could be an answer to that.

See my previous posting, I don't understand what use case this is yet.

> Here are some of the states that I can see on the devices that need to be
> migrated.

> 1. States on switches:
> 1.1  DHCP snooping table on ports;

How often does DHCP snooping take place in data centers? In other
words, is this a real problem, or a theoretical one?

> 1.2  IGMP snooping table on ports;

I think we need to outline some specific scenarios that describe what
the problem actually is here. Who is doing snooping, why, and why a VM
move leaves something not working.

> 1.3  Dynamic ACL which is created by traffic or authentication;

A specific scenario  would be helpful here. Both so I can understand
the details of the problem,  and so we can discuss whether the
scenario is a real problem in existing datacenters today, or just a
theoretical problem.

> 2. States on FW
> 2.1  TCP Connect States
> 2.2  Dynamic ACL

Same as above.


> 3. States on LB
> 3.1  Connect States.
> 3.2  Session States.

Same as above.

> 4. States on IPS/IDS.
> 4.1 Cumulative data

Same as above.

> We can think about two scenarios:
> 1. VM migrate within the subnet under the same FW/LB/IPS. In this case,
> states also migrate under the same FW/LB/IPS etc.
> States need to be migrated include 1.1, 1.2, 1.3.

Before we spend a lot of time on this, we need to establish that there
are actual real scenarios that correspond to real problems happening
in data centers today. If a problem is just theoretical, it becomes
very unclear whether the IETF should do any work (at this time).

I am not interested in discussing solutions, or even the problem in
much detail, if there is no compelling scenario motivating the
problems for which solutions are being considred.

Thomas