Re: [sami] SAMI BoF is rejected.

[Melinda Shore <[e-mail]>]

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