Subject: Re: [nvo3] VM Mobility Draft

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Sep 2014 11:09:19 -0500

Hi Ben, Matthew,

Yes, nvo3 worked on problem statement and issues on VM mobility. I
support progressing Linda's draft.

I just wonder if,  with the new charter, nvo3 will be able work on VM
mobility solutions, including on VXLAN environments?

Regards,

Behcet

On Fri, Aug 29, 2014 at 9:35 PM, Benson Schliesser
<[email-masked]> wrote:
> Hi, Linda -
>
> (I’ve changed the message Subject to better reflect this topic.)
>
> On Aug 29, 2014, at 12:41 PM, Linda Dunbar <[email-masked]> wrote:
>> I think we should decide how to handle this based on a WG discussion about the draft, instead of binding it to the rechartering. It might be worthwhile to have a brief presentation on the draft at the 11-Sep virtual interim meeting - can one of the authors lead this?
>>
>> [Linda] The mobility draft is to address an important area of VM mobility in Data Centers, which the WG had adopted to become WG draft long time ago. We sent request for WG Last call many months ago. But there hasn't been any action. Since the MILESTONEs have separate items for IESG Review and WG adoption for many drafts, it is necessary to list VM Mobility as well.
>
> I see two related questions here. First is the question about whether we need to create a milestone for the VM Mobility draft. Second is whether it is ready for last call.
>
> On the first topic, I don’t see value in debating this, but I will explain my decision. I consider the VM Mobility draft to be a “companion” to the Problem Statement. And I assert that if it is complete (or nearly complete) then a milestone is unnecessary from a management tracking perspective. Thus, we do not need another milestone specifically for a VM Mobility Issues document unless the WG feels that it needs more work, material changes, etc.
>
> On the second topic, personally I agree with you that the VM Mobility Issues draft should be last-called soon. However, I’ve had some private feedback that I’d like to see discussed on the list before we take that step. Specifically, a couple people commented that the draft is unnecessary, questioning whether it adds materially to what is already captured in the Problem Statement. I’m not endorsing this point of view, but nor am I challenging it.
>
> Thus, in my last message I submitted a request for you to present the draft at the upcoming interim meeting, to give us a chance to discuss this feedback. I’m also happy to discus this here on the mailing list. But I’d like to see some kind of response before making a decision to last-call the draft.
>
> Thanks,
> -Benson
>
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 1 Sep 2014 17:16:06 +0000

Behcet,

> -----Original Message-----
> From: nvo3 [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
> Sent: Monday, September 01, 2014 12:09 PM
> To: Benson Schliesser; Bocci, Matthew (Matthew)
> Cc: [email-masked]
> Subject: Re: [nvo3] VM Mobility Draft
> 
> Hi Ben, Matthew,
> 

As a co-author I support progressing the draft. 

If, as Benson said in the e-mail below, there is "some private feedback 
that I’d like to see discussed on the list before we take that step", 
I suggest to discuss this feedback as part of the WG Last Call.

Yakov.

> >> I think we should decide how to handle this based on a WG discussion
> about the draft, instead of binding it to the rechartering. It might be
> worthwhile to have a brief presentation on the draft at the 11-Sep
> virtual interim meeting - can one of the authors lead this?
> >>
> >> [Linda] The mobility draft is to address an important area of VM
> mobility in Data Centers, which the WG had adopted to become WG draft
> long time ago. We sent request for WG Last call many months ago. But
> there hasn't been any action. Since the MILESTONEs have separate items
> for IESG Review and WG adoption for many drafts, it is necessary to list
> VM Mobility as well.
> >
> > I see two related questions here. First is the question about whether
> we need to create a milestone for the VM Mobility draft. Second is
> whether it is ready for last call.
> >
> > On the first topic, I don’t see value in debating this, but I will
> explain my decision. I consider the VM Mobility draft to be a “companion”
> to the Problem Statement. And I assert that if it is complete (or nearly
> complete) then a milestone is unnecessary from a management tracking
> perspective. Thus, we do not need another milestone specifically for a VM
> Mobility Issues document unless the WG feels that it needs more work,
> material changes, etc.
> >
> > On the second topic, personally I agree with you that the VM Mobility
> Issues draft should be last-called soon. However, I’ve had some private
> feedback that I’d like to see discussed on the list before we take that
> step. Specifically, a couple people commented that the draft is
> unnecessary, questioning whether it adds materially to what is already
> captured in the Problem Statement. I’m not endorsing this point of view,
> but nor am I challenging it.
> >
> > Thus, in my last message I submitted a request for you to present the
> draft at the upcoming interim meeting, to give us a chance to discuss
> this feedback. I’m also happy to discus this here on the mailing list.
> But I’d like to see some kind of response before making a decision to
> last-call the draft.
> >
> > Thanks,
> > -Benson
> >
> >

---

From: Benson Schliesser <[email-masked]>
Date: Mon, 1 Sep 2014 14:24:07 -0400

Hi, Yakov and Behcet.

If the private feedback that I referred to doesn't become public on the
mailing list, then for the purpose of my evaluation it doesn't exist.

I will hold off on starting LC for a day or two, just to accommodate the US
holiday...

Cheers,
-Benson

---

From: Benson Schliesser <[email-masked]>
Date: Mon, 1 Sep 2014 15:15:45 -0400

Hi, Anoop, Linda, Ramki, and other contributors -

First, just to be clear, I should remind you that we aren't voting here.
With that in mind, the important thing for you to do is help me resolve the
issue that I asked about.

So, let me ask the question in a slightly different way. You are proposing
that we expand the current text to explicitly identify multicast and
unicast traffic. Does that mean that you intend for the WG to exclude
broadcast traffic?

The current text of the proposed charter is meant to be open to all sorts
of common network traffic. It is nonspecific about what those types of
traffic may be, to avoid giving anybody the impression that we are limiting
the WG work etc. What is the purpose of changing that?

Thanks,
-Benson
On Aug 30, 2014 5:22 PM, "ramki Krishnan" <[email-masked]> wrote:

> Hi Benson,
>
>
>
> [ag] "The NVO3 WG will develop solutions for network virtualization
> covering both unicast and multicast traffic handling based on the following
> architectural tenets:”
>
>
>
> I agree with Linda’s observation and support Anoop’s suggestion for the
> modified charter text.
>
>
>
> Thanks,
>
> Ramki
>
>
>
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Benson
> Schliesser
> *Sent:* Friday, August 29, 2014 7:56 PM
> *To:* [email-masked]
> *Subject:* [nvo3] Multicast issues draft
>
>
>
> Hi, Linda and Anoop -
>
>
>
> (I’ve changed the message Subject to more accurately describe this topic.)
>
>
>
> On Aug 29, 2014, at 6:06 PM, Anoop Ghanwani <[email-masked]> wrote:
>
>
>
>
> [Linda] The entire charter didn't even mention application initiated
> multicast. It is wrong. NVA can eliminate (or reduce) ARP/ND related
> broadcast/multicast, but not application initiated multicast.
>
> The current proposed MILESTONES have separate deliverables for WG adoption
> and FOR IESG review, and very detailed categories being explicitly spelled
> out. Therefore, at minimum, should have one line on the  protocols to
> handle hosts/applications initiated multicast.
>
>
>
> [ag] I agree with Linda here.  While it sounds like there is agreement
> that the problem needs to be addressed by the working group, it would be
> useful to at least have an explicit mention of multicast somewhere in the
> charter.  Perhaps we could change the following line from:
>
> "The NVO3 WG will develop solutions for network virtualization based on the
>
> following architectural tenets:"
>
> to:
>
> "The NVO3 WG will develop solutions for network virtualization covering
> both unicast and multicast traffic handling based on the
>
> following architectural tenets:”
>
>
>
> I’m not opposed to mentioning multicast in the charter, but t wouldn’t be
> my preferred choice.
>
>
>
> The way that I think about it, multicast support is an appropriate topic
> for the requirements drafts. And it should be discussed in the architecture
> draft, as well as any solutions drafts where it might be applicable. But it
> would be sub-optimal to load the charter with a discussion of the various
> types of traffic that might be found in the overlay: broadcast, known and
> unknown unicast, multicast supporting network protocols (such as address
> resolution etc), multicast on behalf of applications (“application specific
> multicast”), etc.
>
>
>
> The current charter text does not exclude work on multicast, which is
> good. And I don’t see any reason to explicitly call it out as a unique
> topic separate from the architecture, control plane, data plane, and use
> cases. If I’m missing something please help me understand. Otherwise I’d
> prefer to leave the proposed charter text as-is.
>
>
>
> Cheers,
>
> -Benson
>
>
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 1 Sep 2014 15:42:00 -0700

Benson,

Broadcast is usually a special case of multicast, so by including
multicast, we would have automatically included broadcast (at least that's
the way I see it).

If, as you suggest, multicast is already within scope because we haven't
explicitly excluded it, then I'm fine with the charter text.  In that
sense, even the milestones can be broadly interpreted as containing
solutions for multicast.  At the very least we will have this thread to
point to, should any questions arise at some point in the future with
regard to scope of the charter.  Hopefully, all folks that would approve
the charter (WG, ADs, IESG, etc.) would be on the same page.

The main reason why I'm bringing this up is that there are existing
implementations that do not support multicast, so in that sense, offering a
solution does not automatically mean that the problem is solved for both
unicast and multicast.  Of course, those are not IETF solutions.

Anoop

On Mon, Sep 1, 2014 at 12:15 PM, Benson Schliesser <[email-masked]>
wrote:

>> architectural tenets:"
>> I agree with Linda's observation and support Anoop's suggestion for the
>> modified charter text.
>>
>>
>>
>> Thanks,
>>
>> Ramki
>>
>>
>>
>> (I've changed the message Subject to more accurately describe this topic.)
>>
>>
>>
>> The current proposed MILESTONES have separate deliverables for WG
>> adoption and FOR IESG review, and very detailed categories being explicitly
>> spelled out. Therefore, at minimum, should have one line on the  protocols
>> to handle hosts/applications initiated multicast.
>>
>>
>>
>> I'm not opposed to mentioning multicast in the charter, but t wouldn't be
>> my preferred choice.
>>
>>
>>
>> resolution etc), multicast on behalf of applications ("application specific
>> multicast"), etc.
>>
>>
>>
>> good. And I don't see any reason to explicitly call it out as a unique
>> cases. If I'm missing something please help me understand. Otherwise I'd

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 2 Sep 2014 10:11:00 -0400

Benson,

I've got a bit of experience when it comes to drafting WG charters. :-)
Especially when working on the milestones, it helps to envision the
expectations for the documents that will be produced by the WG, as there
tends to be a direct correspondence between documents and milestones, so
that milestones can be ticked off as documents are published. There are
currently a couple of multicast-related individual drafts intended for the
WG, however In the current draft charter, there are no specific milestones
related to multicast. If there is a reasonable expectation that at least
one of these drafts will be adopted by the WG and be published as a
stand-alone document, then there should probably be a corresponding
milestone in the charter to track that work.

Thanks,
Andy

On Mon, Sep 1, 2014 at 6:42 PM, Anoop Ghanwani <[email-masked]>
wrote:

>> So, let me ask the question in a slightly different way. You are
>> proposing that we expand the current text to explicitly identify multicast
>> and unicast traffic. Does that mean that you intend for the WG to exclude
>> broadcast traffic?
>>
>>> I’m not opposed to mentioning multicast in the charter, but t wouldn’t
>>> be my preferred choice.
>>>
>>>
>>>

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 2 Sep 2014 07:56:54 -0700

Sounds good, Anoop. I agree that the proposed charter text allows solutions
to support multicast, broadcast, unicast, and whatever other kinds of
common traffic we can imagine.

In any case, if you want to make sure that proposed solutions get this
"right" then I suggest making sure multicast is covered well by the various
requirements documents. Please review them and post comments to the list.

Cheers,
-Benson

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 2 Sep 2014 08:10:50 -0700

Hi, Andy.

I'm always glad for the opportunity to learn from others' experience in
IETF process. Thanks for your advice.

That being said, there are two things that I should point out. First,
Matthew and I do intend to add milestones for each draft that the WG
adopts. These drafts are not yet entirely known, but we expect them to fit
into the categories outlined by the milestones attached to the proposed
charter text. I plan to mark the "category" milestone Done when the
specific drafts (milestones TBD) are all finished. This would include any
multicast solutions that are adopted.

Second, its not clear that the WG will necessarily adopt any of the various
individual drafts that people have written. You are correct that we only
expect to adopt drafts that fit into the scope outlined by the charter. And
just because somebody puts effort into writing a draft does not ensure that
it will be adopted. Likewise, adoption does not guarantee publication. In
all cases we will progress documents based on whether they add
constructively and materially to the WG body of work, and whether there is
consensus to do so.

Cheers,
-Benson
On Sep 2, 2014 7:11 AM, "Andrew G. Malis" <[email-masked]> wrote:

>> On Mon, Sep 1, 2014 at 12:15 PM, Benson Schliesser <[email-masked]
>> > wrote:
>>
>>> The current text of the proposed charter is meant to be open to all
>>> sorts of common network traffic. It is nonspecific about what those types
>>> of traffic may be, to avoid giving anybody the impression that we are
>>> limiting the WG work etc. What is the purpose of changing that?
>>>
>>> Thanks,
>>> -Benson
>>>> The way that I think about it, multicast support is an appropriate
>>>> topic for the requirements drafts. And it should be discussed in the
>>>> architecture draft, as well as any solutions drafts where it might be
>>>> applicable. But it would be sub-optimal to load the charter with a
>>>> discussion of the various types of traffic that might be found in the
>>>> overlay: broadcast, known and unknown unicast, multicast supporting network
>>>> protocols (such as address resolution etc), multicast on behalf of
>>>> applications (“application specific multicast”), etc.
>>>>
>>>>
>>>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Sep 2014 16:10:24 -0500

I don't know why but Yakov jumped on a small part of my message.

Ben, can you spare some comments on this?

 Regards,

Behcet

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 2 Sep 2014 14:25:57 -0700

Hi, Behcet -

The answer to your question is definitely Yes. But just to be clear: NVO3
can work on solutions to networking, based on the architectural tenets
outlined in the charter, to support VM mobility. NVO3 scope would not
include non-network issues etc. (I don't think that's what you're asking,
but I wanted to make sure it is understood.)

Cheers,
-Benson
On Sep 2, 2014 2:10 PM, "Behcet Sarikaya" <[email-masked]> wrote:

> >> > > On Aug 29, 2014, at 12:41 PM, Linda Dunbar <[email-masked]
> >
> >> > wrote:

---

From: Ravi Shekhar <[email-masked]>
Date: Wed, 3 Sep 2014 07:08:23 +0000

Likewise I support progressing the draft as well. Regards.
- Ravi.

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Monday, September 01, 2014 10:16 AM
To: [email-masked]; Benson Schliesser; Bocci, Matthew (Matthew)
Cc: [email-masked]
Subject: Re: [nvo3] VM Mobility Draft

Behcet,

If, as Benson said in the e-mail below, there is "some private feedback that I’d like to see discussed on the list before we take that step", I suggest to discuss this feedback as part of the WG Last Call.

Yakov.

> about the draft, instead of binding it to the rechartering. It might 
> be worthwhile to have a brief presentation on the draft at the 11-Sep 
> for IESG Review and WG adoption for many drafts, it is necessary to 
> list VM Mobility as well.
> >
> perspective. Thus, we do not need another milestone specifically for a 
> VM Mobility Issues document unless the WG feels that it needs more 
> work, material changes, etc.
> >
> Issues draft should be last-called soon. However, I’ve had some 
> private feedback that I’d like to see discussed on the list before we 
> take that step. Specifically, a couple people commented that the draft 
> is unnecessary, questioning whether it adds materially to what is 
> already captured in the Problem Statement. I’m not endorsing this 
> point of view, but nor am I challenging it.
> >

---

From: Thomas Narten <[email-masked]>
Date: Mon, 08 Sep 2014 13:53:07 -0400

> explicitly excluded it, then I'm fine with the charter text.

Of course multicast is already within scope for the WG. I find myself
scratching my head a bit that anyone thinks that it might not be, and
that wording needs to be in the charter on this point. I can't recall
anyone suggesting that suport for tenant multicast should be
out-of-scope. 

IMO, there is no need to specifically mention multicast in the
charter. There is no way the WG or the IESG would allow us to produce
solutions that didn't support multicast. Such a solution would be
pretty deficient.

Does anyone seriously think otherwise?

Thomas

In that sense,
> even the milestones can be broadly interpreted as containing solutions for
> multicast.  At the very least we will have this thread to point to, should any
> questions arise at some point in the future with regard to scope of the
> charter.  Hopefully, all folks that would approve the charter (WG, ADs, IESG,
> etc.) would be on the same page.
> 
>     With that in mind, the important thing for you to do is help me resolve
>     the issue that I asked about.
>    
>     traffic may be, to avoid giving anybody the impression that we are
>         covering both unicast and multicast traffic handling based on the
>         I agree with Linda’s observation and support Anoop’s suggestion for
>         the modified charter text.
> 
>         Thanks,
>        
>         Ramki
> 
>         From: nvo3 [mailto:[email-masked]] On Behalf Of Benson
>         Schliesser
>         Sent: Friday, August 29, 2014 7:56 PM
>         To: [email-masked]
>         Subject: [nvo3] Multicast issues draft
> 
>         Hi, Linda and Anoop -
> 
>             [Linda] The entire charter didn't even mention application
>             initiated multicast. It is wrong. NVA can eliminate (or reduce)
>             ARP/ND related broadcast/multicast, but not application initiated
>             multicast.
>            
>             adoption and FOR IESG review, and very detailed categories being
>             explicitly spelled out. Therefore, at minimum, should have one
>             line on the  protocols to handle hosts/applications initiated
>             multicast.
> 
>         that the problem needs to be addressed by the working group, it would
>         be useful to at least have an explicit mention of multicast somewhere
>         in the charter.  Perhaps we could change the following line from:
>        
>         "The NVO3 WG will develop solutions for network virtualization
>         covering both unicast and multicast traffic handling based on the
>        
>         overlay: broadcast, known and unknown unicast, multicast supporting
>         network protocols (such as address resolution etc), multicast on
>         behalf of applications (“application specific multicast”), etc.
> 
>         topic separate from the architecture, control plane, data plane, and
>         use cases. If I’m missing something please help me understand.
>         Otherwise I’d prefer to leave the proposed charter text as-is.
> 
>         Cheers,
>        
>         -Benson
> 
> [2  <text/plain; us-ascii (7bit)>]

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 11 Sep 2014 07:33:51 -0700

Benson,

> I will hold off on starting LC for a day or two, just to accommodate the US

"a day or two" passed few days ago... When are you going to start
LC on the VM Mobility Draft ?

Yakov.

> > that I=E2=80=99d like to see discussed on the list before we take that st=
> ep",
> > > > (I=E2=80=99ve changed the message Subject to better reflect this topi=
> c.)
> > > >
> > > for IESG Review and WG adoption for many drafts, it is necessary to lis=
> t
> > > VM Mobility as well.
> > > >
> > > > On the first topic, I don=E2=80=99t see value in debating this, but I=
>  will
> > > explain my decision. I consider the VM Mobility draft to be a =E2=80=9C=
> companion=E2=80=9D
> > > to the Problem Statement. And I assert that if it is complete (or nearl=
> y
> > > perspective. Thus, we do not need another milestone specifically for a =
> VM
> > > Issues draft should be last-called soon. However, I=E2=80=99ve had some=
>  private
> > > feedback that I=E2=80=99d like to see discussed on the list before we t=
> ake that
> > > captured in the Problem Statement. I=E2=80=99m not endorsing this point=
>  of view,
> > > this feedback. I=E2=80=99m also happy to discus this here on the mailin=
> g list.
> > > But I=E2=80=99d like to see some kind of response before making a decis=
> ion to
> > > last-call the draft.
> > > >
> > > > Thanks,
> > > > -Benson
> > > >
> > > >
> --001a11c115a0c98f540502051bb8
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> 
> <p dir=3D"ltr">Hi, Yakov and Behcet. </p>
> <p dir=3D"ltr">If the private feedback that I referred to doesn&#39;t becom=
e public on the mailing list, then for the purpose of my evaluation it does=
> n&#39;t exist. </p>
> <p dir=3D"ltr">I will hold off on starting LC for a day or two, just to acc=
> ommodate the US holiday... </p>
> <p dir=3D"ltr">Cheers,<br>
> -Benson<br></p>
> <div class=3D"gmail_quote">On Sep 1, 2014 1:16 PM, &quot;Yakov Rekhter&quot=
> ; &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:=
> <br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:=
> 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Behcet,<br>
> <br>
> &gt; -----Original Message-----<br>
> &gt; From: nvo3 [mailto:<a href=3D"mailto:[email-masked]">nvo3-bounc=
> [email-masked]</a>] On Behalf Of Behcet Sarikaya<br>
> &gt; Sent: Monday, September 01, 2014 12:09 PM<br>
> &gt; To: Benson Schliesser; Bocci, Matthew (Matthew)<br>
> &gt; Cc: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> &gt; Subject: Re: [nvo3] VM Mobility Draft<br>
> &gt;<br>
> &gt; Hi Ben, Matthew,<br>
> &gt;<br>
> &gt; Yes, nvo3 worked on problem statement and issues on VM mobility. I<br>
> &gt; support progressing Linda&#39;s draft.<br>
> <br>
> As a co-author I support progressing the draft.<br>
> <br>
> If, as Benson said in the e-mail below, there is &quot;some private feedbac=
> k<br>
> that I=E2=80=99d like to see discussed on the list before we take that step=
> &quot;,<br>
> I suggest to discuss this feedback as part of the WG Last Call.<br>
> <br>
> Yakov.<br>
> <br>
> &gt;<br>
> &gt; I just wonder if,=C2=A0 with the new charter, nvo3 will be able work o=
> n VM<br>
> &gt; mobility solutions, including on VXLAN environments?<br>
> &gt;<br>
> &gt; Regards,<br>
> &gt;<br>
> &gt; Behcet<br>
> &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt; On Fri, Aug 29, 2014 at 9:35 PM, Benson Schliesser<br>
> &gt; &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>=
> &gt; wrote:<br>
> &gt; &gt; Hi, Linda -<br>
> &gt; &gt;<br>
> &gt; &gt; (I=E2=80=99ve changed the message Subject to better reflect this =
> topic.)<br>
> &gt; &gt;<br>
> &gt; &gt; On Aug 29, 2014, at 12:41 PM, Linda Dunbar &lt;<a href=3D"mailto:=
> [email-masked]">[email-masked]</a>&gt;<br>
> &gt; wrote:<br>
> &gt; &gt;&gt; I think we should decide how to handle this based on a WG dis=
> cussion<br>
> &gt; about the draft, instead of binding it to the rechartering. It might b=
> e<br>
> &gt; worthwhile to have a brief presentation on the draft at the 11-Sep<br>
> &gt; virtual interim meeting - can one of the authors lead this?<br>
> &gt; &gt;&gt;<br>
> &gt; &gt;&gt; [Linda] The mobility draft is to address an important area of=
>  VM<br>
> &gt; mobility in Data Centers, which the WG had adopted to become WG draft<=
> br>
> &gt; long time ago. We sent request for WG Last call many months ago. But<b=
> r>
> &gt; there hasn&#39;t been any action. Since the MILESTONEs have separate i=
> tems<br>
> &gt; for IESG Review and WG adoption for many drafts, it is necessary to li=
> st<br>
> &gt; VM Mobility as well.<br>
> &gt; &gt;<br>
> &gt; &gt; I see two related questions here. First is the question about whe=
> ther<br>
> &gt; we need to create a milestone for the VM Mobility draft. Second is<br>
> &gt; whether it is ready for last call.<br>
> &gt; &gt;<br>
> &gt; &gt; On the first topic, I don=E2=80=99t see value in debating this, b=
> ut I will<br>
> &gt; explain my decision. I consider the VM Mobility draft to be a =E2=80=
> =9Ccompanion=E2=80=9D<br>
> &gt; to the Problem Statement. And I assert that if it is complete (or near=
> ly<br>
> &gt; complete) then a milestone is unnecessary from a management tracking<b=
> r>
> &gt; perspective. Thus, we do not need another milestone specifically for a=
>  VM<br>
> &gt; Mobility Issues document unless the WG feels that it needs more work,<=
> br>
> &gt; material changes, etc.<br>
> &gt; &gt;<br>
> &gt; &gt; On the second topic, personally I agree with you that the VM Mobi=
> lity<br>
> &gt; Issues draft should be last-called soon. However, I=E2=80=99ve had som=
> e private<br>
> &gt; feedback that I=E2=80=99d like to see discussed on the list before we =
> take that<br>
> &gt; step. Specifically, a couple people commented that the draft is<br>
> &gt; unnecessary, questioning whether it adds materially to what is already=
> <br>
> &gt; captured in the Problem Statement. I=E2=80=99m not endorsing this poin=
> t of view,<br>
> &gt; but nor am I challenging it.<br>
> &gt; &gt;<br>
> &gt; &gt; Thus, in my last message I submitted a request for you to present=
>  the<br>
> &gt; draft at the upcoming interim meeting, to give us a chance to discuss<=
> br>
> &gt; this feedback. I=E2=80=99m also happy to discus this here on the maili=
> ng list.<br>
> &gt; But I=E2=80=99d like to see some kind of response before making a deci=
> sion to<br>
> &gt; last-call the draft.<br>
> &gt; &gt;<br>
> &gt; &gt; Thanks,<br>
> &gt; &gt; -Benson<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; _______________________________________________<br>
> &gt; &gt; nvo3 mailing list<br>
> &gt; &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> &gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/nvo3" target=3D"=
> _blank">https://www.ietf.org/mailman/listinfo/nvo3</a><br>
> &gt;<br>
> &gt; _______________________________________________<br>
> &gt; nvo3 mailing list<br>
> &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/nvo3" target=3D"_blan=
> k">https://www.ietf.org/mailman/listinfo/nvo3</a><br>
> </blockquote></div>
> 
> --001a11c115a0c98f540502051bb8--