[sami] SAMI BoF is rejected.

["Guyingjie (Yingjie)" <[e-mail]>]

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.

Martin, 

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:[e-mail]] 
发送时间: 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 
draft-xu-behave-stateful-nat-standby).

Long behave WG thread starting with 
http://www.ietf.org/mail-archive/web/behave/current/msg07424.html
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)
draft-xu-behave-lsn-standby
draft-li-behave-dns64-load-balancing
draft-chen-behave-olnat
draft-chen-behave-rsnat
draft-wang-behave-nat64-load-balancer
draft-zhang-behave-nat64-load-balancing
******************************************************************

Regards,

   Martin

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
>

-- 
[e-mail]

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