Re: [sami] FW: New Version Notification for draft-gu-statemigration-framework-00.txt
"Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> Tue, 10 July 2012 17:17 UTC
Return-Path: <ssenthil@cisco.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 949F621F87C1 for <sami@ietfa.amsl.com>; Tue, 10 Jul 2012 10:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.845
X-Spam-Level:
X-Spam-Status: No, score=-8.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8]
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 Fj4PLdnHH-2B for <sami@ietfa.amsl.com>; Tue, 10 Jul 2012 10:17:38 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4A48021F87C0 for <sami@ietf.org>; Tue, 10 Jul 2012 10:17:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=11304; q=dns/txt; s=iport; t=1341940686; x=1343150286; h=from:to:cc:subject:date:message-id:mime-version; bh=lSD6FOhaQ8rpWIj1k+g7yr/6sf0ejqkxkSofvQA97wM=; b=eBph97EsB/QF0l/clKJzPwwtm0+SAmnM42c21ZJyiArhW0kZ61WOQ5+y mt3Z62kwl1LUsXRJDsjRP5ODjoLzWYUWNt+AHtMPaw6hACIjqmSo/0mZo L6kxTpxjDmmaMyoR79uhrvODu0x84ye1ecICVrkfHlDNx71n04rIXs12Q Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAElj/E+tJV2c/2dsb2JhbABFgkqDHLB2gRyBB4IgAQIEEgFkAhIBCEQEMBwLBA4gB4drnHqNEgWTG5BLgRcDlTaOH4Fmgl8
X-IronPort-AV: E=Sophos; i="4.77,560,1336348800"; d="scan'208,217"; a="100513038"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jul 2012 17:18:06 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6AHI6iY000366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jul 2012 17:18:06 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.21]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 12:18:05 -0500
From: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
To: "david.black@emc.com" <david.black@emc.com>
Thread-Topic: [sami] FW: New Version Notification for draft-gu-statemigration-framework-00.txt
Thread-Index: AQHNXr/3U5Eu9+jdUUChAQVIiGSW1g==
Date: Tue, 10 Jul 2012 17:18:05 +0000
Message-ID: <CC21DC0A.2C8D1%ssenthil@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.2.120421
x-originating-ip: [10.150.25.103]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19030.006
x-tm-as-result: No--24.894600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_CC21DC0A2C8D1ssenthilciscocom_"
MIME-Version: 1.0
Cc: "sami@ietf.org" <sami@ietf.org>
Subject: Re: [sami] FW: New Version Notification for draft-gu-statemigration-framework-00.txt
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: Tue, 10 Jul 2012 17:17:39 -0000
Hi David, Thank your for your review and comments, please see inline for [Senthil] I generally like this draft - I've sent a bunch of comments directly to the authors, many of which are editorial. OTOH, the 4.2 State vs. Policy section appears worthy of a wider discussion. This section appears to introduce a concept of a related set of middleboxes- the rough operational definition is "the set of middleboxes across which policy has to be uniformly provisioned in order to obtain consistent policyenforcement in the presence of middlebox state migration". This seems rather important to understanding the likely scope of deployment and the administrative characteristics of state migration so I'd suggest more text on this conceptin that section or somewhere nearby. This also relates to discussion of middleboxes knowing about each other in the second paragraph of Section 6. In addition, with respect to the concerns in at least section 7.2, this leans towards a heavy reliance on configuration for (or to support) discovery. [Senthil] I believe that the state migration can happen only between boxes that are in a cooperative administrative domain. Because this would require some explicit and some implicit Configuration parameters so that the middle boxes work in tandem to facilitate the state information. I mention a cooperative administrative domain because I don¹t want to say that it MUST be in the same administrative domain - an example of co-operative admin domain would be an enterprise but operated out of different data centers etc. The same thing with VM migrations, any random VM cannot take over from an active VM, they must be in a co-operative administrative domain. Maybe that was not explicit enough in the draft that we should make it explicit enough. One would want to provide state migration and synchronization as a service to its customers/employees. In other words you don¹t want to provide this as a free service as the cost of doing this is significant (either redundancy, CPU cycles and network bandwidth), so providing this as a service, in a common administrative domain is definitely the premise, IMO. Thanks Senthil The fact that this topic touches upon multiple sections is indicative of its importance, and it feels like a good "place to dig" to come up with an initial state migration problem scenario/subset) that might be solvable in a reasonable period of time. The sort of thing I have in mind is that if the middleboxes are under common administration, and are in the same administrative domain as the attachment points across which the endpoint movement occurs, a number of the hard problems in Section 7 (e.g., discovery) are amenable to solution via configuration and the security discussion is qualitatively rather different from what's in Section 8. Thanks, --David
- [sami] FW: New Version Notification for draft-gu-… Guyingjie (Yingjie)
- Re: [sami] FW: New Version Notification for draft… david.black
- Re: [sami] FW: New Version Notification for draft… Senthil Sivakumar (ssenthil)