Subject: [sami] SAMI BoF is rejected.

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Sat, 29 Sep 2012 01:19:36 +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.

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:[email-masked]] 
发送时间: 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
>

-- 
[email-masked]

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

---

From: Melinda Shore <[email-masked]>
Date: Fri, 28 Sep 2012 18:48:03 -0800

On 9/28/12 5:19 PM, Guyingjie (Yingjie) wrote:
> Besides, as suggested by ADs, Melinda has made a brief research on
> BEHAVE, 

The issue here isn't behave, per se, but that some drafts
were discussed in behave that appear to have some similarities
(i.e. state sync between NATs), and ultimately the working
group decided against adopting them.

So, I read all of the drafts in question in detail and here's the
situation:  The work that was not accepted dealt specifically with 1)
NATs, and 2) NATs that were tightly bound to one another -
high-availability and load balancing scenarios.  The drafts that dealt
with that mostly introduced a protocol for conveying the NAT state, to
keep NAT devices in sync.

Heaven knows that we are aware of substantial existing work
dealing with conveying or instantiating middlebox state -
the IETF has been grappling with that since the late 1990s.
I'm currently in the process of adding an "existing/related
work" section to the framework draft, and it's a *lot* of stuff.
However, what's really gotten the bulk of the focus is frameworks
for NAT traversal by VoIP protocols, which assume a
particular architecture, and protocols for installing firewall
pinholes and/or NAT table mappings.  What's gotten far less
attention, and the problem that we're looking at, is related
to topology and to middlebox discovery, as well as issues
around timing and reliability.  It is almost certainly the case
that we'll be able to leverage an existing protocol to carry
requests around the network, but we'll still need to figure
out how to identify which middleboxes are involved when an
endpoint changes its point of attachment to a network.

So, we've still got some foundational work to do, which is pretty
much par for the course in bringing new work to the IETF.  I do
believe that this really is new work, there's demand from the
community, and we've got a strong case to make.

Melinda