Re: [sami] SAMI BoF is rejected.

Melinda Shore <melinda.shore@gmail.com> Sat, 29 September 2012 02:48 UTC

Return-Path: <melinda.shore@gmail.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 94C3021F84DC for <sami@ietfa.amsl.com>; Fri, 28 Sep 2012 19:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.496
X-Spam-Level:
X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR5XZDmljXNh for <sami@ietfa.amsl.com>; Fri, 28 Sep 2012 19:48:08 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8E21F84D6 for <sami@ietf.org>; Fri, 28 Sep 2012 19:48:07 -0700 (PDT)
Received: by pbbro8 with SMTP id ro8so5881643pbb.31 for <sami@ietf.org>; Fri, 28 Sep 2012 19:48:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WCv+TP25BR0X+aG1yCr4Tk8IV/LeJRIvr/eo+XSsFIA=; b=bRKphAab3IPv0RSxw28pahHOFccoNyNieI8IEv+yvJVeXCf1OQJVF08gQZkLQN/MOS DL/9zA4jthP2ISYv7C00OiZciwK7rFE/rYmvQlZPkKWCCzlzYUFFb61bWLC3mc8K3U0M VI477WjhFhkrXDYqXK+YF+++N36C+b4psnzH1sy743lYujIw6o3rhgrc0hlMXAaf8/iT LYtiJYJiTq/FyNEePI+TXZfoXw/M8ahm4v4bATS2uxIDeJUqx6Q2mdVDSbsPff1TSiOw gLIMUo+DPbgfnbcfyTavlv51ujbAOtQwSwmm+bqJ1tY5PDAUbwxNsYbzWrVYas+n3T74 UrbA==
Received: by 10.66.76.165 with SMTP id l5mr21476277paw.79.1348886887662; Fri, 28 Sep 2012 19:48:07 -0700 (PDT)
Received: from spandex.local (66-230-86-185-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.86.185]) by mx.google.com with ESMTPS id i1sm6456411pay.26.2012.09.28.19.48.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Sep 2012 19:48:07 -0700 (PDT)
Message-ID: <50666163.1070800@gmail.com>
Date: Fri, 28 Sep 2012 18:48:03 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "Guyingjie (Yingjie)" <guyingjie@huawei.com>
References: <A27496C192613C44A82D819E1B98DB573405C9DA@SZXEML511-MBS.china.huawei.com>
In-Reply-To: <A27496C192613C44A82D819E1B98DB573405C9DA@SZXEML511-MBS.china.huawei.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: 'Wesley Eddy' <wes@mti-systems.com>, Martin Stiemerling <martin.stiemerling@neclab.eu>, "sami@ietf.org" <sami@ietf.org>
Subject: Re: [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 02:48:08 -0000

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