Subject: [nvo3] Middleboxes during a VM migration

From: Melinda Shore <[email-masked]>
Date: Fri, 22 Feb 2013 19:51:23 -0900

Hi:

We've been working on the problem of middlebox traversal
when a VM migrates (or, for that matter, a network migrates)
and since VM migration is within the nvo3 charter we'd like
to get some feedback and input on our drafts.  They are:

https://datatracker.ietf.org/doc/draft-gu-statemigration-framework/
https://datatracker.ietf.org/doc/draft-gu-statemigration-arch/

If there's interest and there's time, we'd also ask for time
for discussion during the meeting at IETF 86.

Thanks,

Melinda

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Feb 2013 11:23:16 +0200

Hi Melinda,

I just spotted a bug:

8.4. NSIS NAT/Firewall signaling layer

    The NSIS [RFC5971] working group specified a NAT and firewall
    signaling (control) layer to run on top of its GIST transport.  Tne
    signaling runs end-to-end between signaling endpoints and has no
    mechanism for discovery of middleboxes not on the signaling path.

NSIS also supports non-end-to-end scenarios. See Section 2 of 
http://tools.ietf.org/html/rfc5973.

This functionality was introduced to provide an ability for deploying 
the protocol incrementally.

Also, there was work on discovering middleboxes not on the path. While 
this work was never finished (the IESG at that time did not like 
non-off-path signaling approaches) here is the document:
http://tools.ietf.org/html/draft-hancock-nsis-pds-problem-04

In a nutshell NSIS was really developed to be fairly generic.

TURN: If you mention TURN then you also have to talk about other 
tunneling protocols as well, such as MIP or a regular IPsec VPN. They 
basically provide the same functionality.

I also noticed that an approach using Diameter for middlebox signaling 
was missing. Teleco operators are quite excited about Diameter. Here are 
the references:
http://tools.ietf.org/html/rfc6736
http://tools.ietf.org/html/rfc5777

I don't know whether telco operators are within the scope of this group 
(or whether this is a more enterprise networks driven gang).

But I suspect that you don't want to be exhaustive in your investigation.

Ciao
Hannes

On 02/23/2013 06:51 AM, Melinda Shore wrote:
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Melinda Shore <[email-masked]>
Date: Sat, 23 Feb 2013 18:50:07 -0900

> In a nutshell NSIS was really developed to be fairly generic.

I think nsis is a truly heinous protocol, but that's not really
important.  We needed to document relevant protocols because
people kept asking if we'd thought about this one or that one.
I've done a pile of middlebox protocols myself, and brought both
the initial midcom work and the stuff that metastasized into
nsis into the IETF to start with.

But, what we're really interested in doing is taking a look at
the overall picture and identifying where there's no existing
tool (or solution, if you will), since the IETF has tended to
punt on some of the more challenging problems around topology
and whatnot.  We've got a great heap of protocols to communicate
with middleboxes but we're missing a lot of the structure that
we'd need to move flow-associated state to a new middlebox as
a network flow has endpoints migrating.

Melinda