[sami] SAMI BoF is rejected.

"Guyingjie (Yingjie)" <guyingjie@huawei.com> Sat, 29 September 2012 01:20 UTC

Return-Path: <guyingjie@huawei.com>
X-Original-To: sami@ietfa.amsl.com
Delivered-To: sami@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5202F21F859B for <sami@ietfa.amsl.com>; Fri, 28 Sep 2012 18:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.396
X-Spam-Status: No, score=-103.396 tagged_above=-999 required=5 tests=[AWL=-1.339, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id m2Mlap2l0RW0 for <sami@ietfa.amsl.com>; Fri, 28 Sep 2012 18:20:14 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7D56621F856C for <sami@ietf.org>; Fri, 28 Sep 2012 18:20:13 -0700 (PDT)
Received: from (EHLO lhreml204-edg.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALD62114; Sat, 29 Sep 2012 01:20:12 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com ( by lhreml204-edg.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:18:55 +0100
Received: from SZXEML414-HUB.china.huawei.com ( by lhreml405-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:19:42 +0100
Received: from SZXEML511-MBS.china.huawei.com ([]) by SZXEML414-HUB.china.huawei.com ([]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 09:19:37 +0800
From: "Guyingjie (Yingjie)" <guyingjie@huawei.com>
To: "sami@ietf.org" <sami@ietf.org>
Thread-Topic: SAMI BoF is rejected.
Thread-Index: AQHNneB9VORyftg9ZEOvtG3eW0XFPA==
Date: Sat, 29 Sep 2012 01:19:36 +0000
Message-ID: <A27496C192613C44A82D819E1B98DB573405C9DA@SZXEML511-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: 'Wesley Eddy' <wes@mti-systems.com>, Martin Stiemerling <martin.stiemerling@neclab.eu>
Subject: [sami] SAMI BoF is rejected.
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: Sat, 29 Sep 2012 01:20:15 -0000

I am sorry to say that SAMI BoF is rejected by ADs, and the following are the reasons that ADs give to us and my replies to ADs. I think it's better to let the mail list know of the discussion. 

Besides, as suggested by ADs, Melinda has made a brief research on BEHAVE, and I talked with an author of draft-xu-behave-nat-state-sync, we think SAMI and BEHAVE has significant difference. The work in BEHAVE is working in Large scale network and Carrier Grade Network, to sync the state between a pair of redundant NATs for High availability reason. While SAMI is working in VM Live migration scenario in DC, and the state is supposed to be transferred between any two middleboxes with same functions, e.g. FWs, who are not supposed to be HA pairs. 

Please send any of your comments to the mail list. 

Though we are rejected for a BoF, but ADs offer a presentation slot at TSVAREA. Hope to see you there.

Best Regards
Gu Yingjie

发件人: Guyingjie (Yingjie) 
发送时间: 2012年9月28日 乐乐13:47
收件人: 'Martin Stiemerling'
抄送: 'Wesley Eddy'; Benson Schliesser; Melinda Shore
主题: 答复: State Migration BoF proposal for Altanta Meeting.


Yes, we would like to present at TSVAREA and try to answer some of your questions. And thank you for this offer.

As short answer to you questions:
1. State Migration is more than NAT, and in our drafts and discussion in mail list, we focus on Firewall. And the state migration for Firewall and NAT has significant difference I believe. 

2. Many operators and vendors show there interest, including Verizon, China Telecom, China Mobile, EMC, HP, Ruijie and etc. Huawei itself is a vendor of Middlebox, e.g. Firewall, so does Ruijie and other main network device vendors, like Cisco. So I think the vendors can definitely represents a part of middlebox vendors. Of course, we will still try to get more opinions from other dedicated middlebox vendors. Just that they are not very active and interested in attending SDOs.

3. Yes, I agree that SAMI has been silent for a while. But that has a reason. If you go through the email archive, you will find that we have a lot of discussion. Subscribers do pay a lot of attention and enthusiasm in State Migration discussion at the very beginning. But since we don't have a solid place to work on it, i.e. a WG, the mail list topic is restricted to whether the problem exist and it's easy to get to a discussion bottleneck after everyone argue with their own background. Unlike some other BoF mail list which may be established just before BoF request so the mail list show a good activity, SAMI mail list may be silent for now, but it does include very good nutrition. The mail list just need a new trigger, e.g. if we can go a little deeper into use case or even technical discussion, but this is not appropriate before a WG is designated. 

Best Regards
Gu Yingjie

发件人: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu] 
发送时间: 2012年9月27日 乐乐18:11
收件人: Guyingjie (Yingjie)
抄送: 'Wesley Eddy'; Benson Schliesser; Melinda Shore
主题: Re: State Migration BoF proposal for Altanta Meeting.

Yingjie, all,

The State Migration BOF was not approved, as you have already seen.

However, we invited you to present the proposal at the TSVAREA meeting 
at the coming IETF meeting in Atlanta. Let us know until Oct 4th, if you 
accept this or not.

Now to the points that have to be answered before this can be a BoF:
- The migration of middlebox state was discussed a while back in the 
BEHAVE WG and it pushed back there. Please check the details below 
marked as Dave Thaler's hints.
- It is not clear if there is any interest of middlebox vendors to have 
a standardized protocol to transfer state. The main reason is that the 
state of each vendor's implementation is so different from any other 
vendor that it can be impossible to reach a standard way of exchanging 
this information.
- The sami mailing list is dead since several weeks. It is necessary to 
discuss the **current** proposal there, in order to show if there is 
community interest, and also to elaborate the above details.

Dave Thaler's hint to the BEHAVE WG:
For example, in IETF 77 proceedings you can see the discussion of 
draft-xu-behave-nat-state-sync (and to a lesser extent 

Long behave WG thread starting with 
contains most of the main arguments.

In terms of who proposers were, the drafts that had a similar flavor of 
interactions between middleboxes in the same network:
draft-xu-behave-nat-state-sync (the main one mentioned above)



On 09/24/2012 03:09 AM, Guyingjie (Yingjie) wrote:
> Hi Martin and Wes,
> The attached is the BoF proposal about State Migration for IETF85 at
> Atlanta. Please let us know if there is anything else we should clarify
> or provide.
> ------------------------------------------------------------------------
> Best Regards
> Gu Yingjie


NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283