Subject: [tsvwg] 转发: New Version Notification for draft-gu-statemigration-framework-00.txt

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Wed, 4 Jul 2012 04:08:10 +0000

Hi all,
We have submitted a draft named as draft-gu-statemigration-framework-00. I used to present the problem at TSVWG once, if anybody happened to remember this. :)

The abstract is as follows. And we think the experts in TSVWG may be interested in it. 

We are looking forward to your comments.

Best Regards
Gu Yingjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2012年7月4日 乐乐3:05
收件人: [email-masked]
抄送: Guyingjie (Yingjie); [email-masked]
主题: New Version Notification for draft-gu-statemigration-framework-00.txt

A new version of I-D, draft-gu-statemigration-framework-00.txt
has been successfully submitted by Melinda Shore and posted to the
IETF repository.

Filename:	 draft-gu-statemigration-framework
Revision:	 00
Title:		 A Framework and Problem Statement for Flow-associated Middlebox State Migration
Creation date:	 2012-07-03
WG ID:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-gu-statemigration-framework-00.txt
Status:          http://datatracker.ietf.org/doc/draft-gu-statemigration-framework
Htmlized:        http://tools.ietf.org/html/draft-gu-statemigration-framework-00

Abstract:
   This document presents an initial framework and discussion of the
   problem of transferring middlebox (for example, firewall or NAT)
   flow-coupled state from one middlebox to another while the flow is
   still active.  This has most recently come up in the context of
   virtual machine (VM) migration between hypervisors, but it is a
   problem that has appeared in other situations, as well.  We present
   some of the parameters of the problem, define some language for
   discussing the problem, and begin to identify a path forward for
   addressing it.

The IETF Secretariat

---

From: <[email-masked]>
Date: Thu, 5 Jul 2012 19:51:34 -0400

Should this draft be discussed in tsvwg or in tsvarea?

Much as I'm interested in this problem area, it's not at all clear to me that work on the problem described in this draft is something that tsvwg should take up.

With my Transport Directorate member hat on, I would support a discussion of this problem area in tsvarea towards figuring out how well it fits into the Transport Area and what to do about it.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Guyingjie (Yingjie)
> Sent: Wednesday, July 04, 2012 12:08 AM
> To: [email-masked]
> Cc: Melinda Shore; Senthil Sivakumar (ssenthil)
> Subject: [tsvwg] 转发: New Version Notification for draft-gu-statemigration-
> framework-00.txt
> 
> Hi all,
> We have submitted a draft named as draft-gu-statemigration-framework-00. I
> used to present the problem at TSVWG once, if anybody happened to remember
> this. :)
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Jul 2012 15:59:48 -0800

On 7/5/12 3:51 PM, [email-masked] wrote:
> With my Transport Directorate member hat on, I would support a
> discussion of this problem area in tsvarea towards figuring out how
> well it fits into the Transport Area and what to do about it.

That's our hope.  There's been considerable work done in the
transport area over the last <bignum> years on related problems
and we see some continuity from the work done in midcom and
the firewall/NAT work in nsis to this problem.  I agree that
this does not seem like a candidate for a tsvwg work item.

Melinda

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 23 Jul 2012 14:50:26 +0200

David,

We have had a presentation about this (or in my understanding at least 
related) at the IETF 82 TSVAREA meeting in Quebec:
http://www.ietf.org/proceedings/81/slides/tsvarea-1.pdf

However, at this time it did not attract the attendees too much.

This might have changed, but I would like to see some more discussion 
about this updated draft on the sami mailing list.

  Martin

-- 
[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: <[email-masked]>
Date: Mon, 23 Jul 2012 09:23:56 -0400

Martin,

The draft has changed quite a bit since then - this draft is the successor
to the much broader draft that was the subject of that Quebec presentation. 

Given the considerable narrowing of the draft's scope, I hope people will
take another look and comment (e.g., on the sami list).

Thanks,
--David

> From: Martin Stiemerling [mailto:[email-masked]]
> Sent: Monday, July 23, 2012 8:50 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tsvwg] 转发: New Version Notification for draft-gu-
> statemigration-framework-00.txt
> 
> David,
> 
> > Much as I'm interested in this problem area, it's not at all clear to me
> that work on the problem described in this draft is something that tsvwg
> should take up.
> >
> > With my Transport Directorate member hat on, I would support a discussion of
> this problem area in tsvarea towards figuring out how well it fits into the
> Transport Area and what to do about it.
> >
> > Thanks,
> > --David
> >
> >> URL:             http://www.ietf.org/internet-drafts/draft-gu-
> statemigration-
> >> framework-00.txt
> >> Htmlized:        http://tools.ietf.org/html/draft-gu-statemigration-
> framework-
> >> 00
> >>
> >>
> >> Abstract:

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Jul 2012 08:34:07 -0800

> about this updated draft on the sami mailing list.

The draft is entirely rewritten and scoped and I think it's much
clearer in describing the problem and what would need to be addressed.
Right now there's a discussion of VM migration taking place on the
NVO3 mailing list.  The need to be able to move network endpoints
but moving associated middlebox state is outside the scope of their
working group.

Because previous middlebox signaling work took place within the
transport area (and here I'm thinking of nsis and midcom) it appear
that the transport area is a locus of both interest and expertise,
and we're hoping for feedback on the rewritten document.

Melinda

---

From: <[email-masked]>
Date: Tue, 24 Jul 2012 04:10:23 +0000

Hi Melinda,

I think that one other challenge associated with the transfer of middlebox state is the support of service continuity.

Regarding the discussion on the problem space, I think that it could probably be interesting to also describe what is the main difference between the problems that this draft is talking about and the problems & possible solutions mentioned in the RFCs on Context Transfer, see below:

http://www.rfc-editor.org/rfc/rfc3374.txt

http://www.rfc-editor.org/rfc/rfc4067.txt

Best regards,
Georgios

________________________________________
Van: [email-masked] [[email-masked]] namens Melinda Shore [[email-masked]]
Verzonden: maandag 23 juli 2012 18:34
Aan: Martin Stiemerling
CC: [email-masked]
Onderwerp: Re: [tsvwg] 转发: New Version Notification for draft-gu-statemigration-framework-00.txt

Melinda

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 24 Jul 2012 11:19:53 +0200

Melinda,

Taking up Georgios points about the context transfer protocol.

I remember discussions in Taipei with Yingjie about the prior version of
the draft and the view that there is an issue with migrating state
between middleboxes.

However, I've also asked if the  Context Transfer Protocol (CXTP)  could
be the solution and if it is not the solution (or only a partial one)
what are the missing parts on the protocol level.

I see still this as the big open question to be answered by this draft.

Any news about that?

  Martin

---

From: Melinda Shore <[email-masked]>
Date: Tue, 24 Jul 2012 09:04:10 -0800

> I see still this as the big open question to be answered by this draft.

No, not yet.  This is the first time I've heard it being raised as
an issue.  I'll take care of it.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 24 Jul 2012 09:20:53 -0800

> what are the missing parts on the protocol level.

CTXP may indeed turn out to be a part of a solution but at this
point we've really been focused on getting a handle on the problem -
scope, in particular, and understanding which problems would need
to be solved.  There are clearly some problems around locating
the middleboxes that are being traversed, since they are not
signaling endpoints in a VM migration scenario and would not "know"
that they need to transfer a given chunk of state associated with
a network flow.

You're correct that this does need to be addressed but I think that
the underlying architectures/scenarios are quite different and that
even if CTXP turns out to be a useful protocol there'd still need
to be work done around topology and the question of who's sending
triggers to whom.

Thanks,

Melinda