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

Warren Kumari <warren@kumari.net> Mon, 29 August 2011 17:19 UTC

Return-Path: <warren@kumari.net>
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 3215E21F8A97 for <sami@ietfa.amsl.com>; Mon, 29 Aug 2011 10:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.447
X-Spam-Level:
X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, 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 wzMCAC9MhxQu for <sami@ietfa.amsl.com>; Mon, 29 Aug 2011 10:18:59 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2345421F8A96 for <sami@ietf.org>; Mon, 29 Aug 2011 10:18:58 -0700 (PDT)
Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 1EFCC1B416C1; Mon, 29 Aug 2011 13:20:21 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <201108251311.p7PDB8e1019968@cichlid.raleigh.ibm.com>
Date: Mon, 29 Aug 2011 13:20:20 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E65C50E-F8F2-46D9-8675-0894B64B6D59@kumari.net>
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> <201108251311.p7PDB8e1019968@cichlid.raleigh.ibm.com>
To: Thomas Narten <narten@us.ibm.com>
X-Mailer: Apple Mail (2.1084)
Cc: sami@ietf.org
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: Mon, 29 Aug 2011 17:19:00 -0000

On Aug 25, 2011, at 9:11 AM, Thomas Narten wrote:

> "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.

Yup.

> 
>> 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).

Yes.

> 
> 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.

My message here is basically content free, I just wanted to support / agree with what Thomas said -- this is fairly unusual, so worth noting...

W

> 
> Thomas
> _______________________________________________
> sami mailing list
> sami@ietf.org
> https://www.ietf.org/mailman/listinfo/sami
>