Subject: Re: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC

From: Thomas Narten <[email-masked]>
Date: Mon, 02 Jun 2014 13:36:11 -0400

I've followed the discussion on this thread and want to  go back to
something folk may have forgotten.

More than a year ago, the WG made a considered and conscious decision
to "ship" the framework documemnt more or less "as is" and start work
on a followup architecure document. It was known and expected that the
architecture document would become the focus of work moving forward
and that substantive additions/changes would go there. Even if it
meant the framework document would be less complete.

Sadly, it has been more than a year since that decision was made, yet
the framework document appears stalled and unable to get
published. I'll note that the problem statement document to which the
framework is a companion, has been languishing in the RFC editor queue
for almost a year now, blocked on a normative reference to the
definitions in the framework document.

FWIW, I think the framework is good enough to publish more-or-less as
is. Or more to the point, there just isn't energy to make significant
changes to the document given that the focus of the WG has long since
moved to the architecture document.
 
If folk have substantive issues with the framework, I'd strongly
suggest first looking at the architecture
(draft-ietf-nvo3-arch-01.txt) and seeing whether their concern exists
there, and of so, whether the archictecture document would be a better
place to address the concern.

Thomas

---

From: Barry Leiba <[email-masked]>
Date: Mon, 2 Jun 2014 14:30:28 -0400

> place to address the concern.

Does that mean that the working group would be willing to pull the
architecture document back out of the RFC Editor queue for rework,
should it come to that?

Barry

---

From: "Black, David" <[email-masked]>
Date: Mon, 2 Jun 2014 14:44:01 -0400

Barry,

> architecture document back out of the RFC Editor queue for rework,

There appears to be some confusion here:

The nvo3 architecture draft is not in RFC Editor queue, it's still with the WG:
http://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/

The nvo3 problem statement draft is in the RFC Editor queue:
http://datatracker.ietf.org/doc/draft-ietf-nvo3-overlay-problem-statement/

I haven't seen anything in this discussion that suggests pulling
the latter draft back from the RFC Editor.

Thanks,
--David (co-author of both of the above drafts)

> -----Original Message-----
> From: nvo3 [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Monday, June 02, 2014 2:30 PM
> To: Thomas Narten
> Cc: [email-masked]; [email-masked]; Linda Dunbar
> Subject: Re: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework
> for DC Network Virtualization) to Informational RFC
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Thomas Narten <[email-masked]>
Date: Mon, 02 Jun 2014 14:48:00 -0400

> architecture document back out of the RFC Editor queue for rework,

Not necessary.

To clarify, the problem statement document
(draft-ietf-nvo3-overlay-problem-statement-04.txt) is in the RFC
editor queue. It has a normative dependence on the framework document
- it shares common terminology.

The architecure document is a relatively new document and is still in
the WG and will surely be there for some time. The architecture would
be published along with solutions (which the WG isn't even chartered
to do yet!) because the architecture and solutions clearly have to
very much be in sync.

AFAICT, none of discussions in the last year on the framework document
would have any impact the problem statement.

Thomas

---

From: Barry Leiba <[email-masked]>
Date: Mon, 2 Jun 2014 14:55:08 -0400

> There appears to be some confusion here:

There does, indeed: I didn't read Thomas's note carefully enough, and
misunderstood.  Got it now; thanks.

Barry

---

From: Alia Atlas <[email-masked]>
Date: Mon, 2 Jun 2014 14:58:38 -0400

Thomas,

The NVO3 Framework draft is in IETF Last Call, which isn't precisely
stalled.
It is true that Linda and Lucy have raised some concerns about it.

I have not yet heard from the WG chairs or authors whether the desired
changes
have been previously discussed and had consensus determined in the WG.
 Linda indicated that her
comments had already been discussed on the nvo3 mailing list.  Lucy is
requesting that different
technology be indicated as examples - perhaps to give a sense of future
possible solutions to the
readers of the draft.

If there is WG consensus to make a few minor edits, that can be done before
the
IESG review next week.  It is on the next telechat, so I would appreciate
speed in
resolving the minor comment.

Regards,
Alia

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Tue, 3 Jun 2014 08:01:14 +0000

Alia,

I have replied and suggested some minor edits to address Linda and Lucy's comments. I have suggested to be protocol agnostic rather than giving specific examples in the multi-homing case.
Some of Linda's comments have been discussed at length in the past and there was clear WG consensus that the framework draft addressed NVO3's problem.

Let me know if you want me to post a revised draft based on these minor edits and some other suggested edits from other IETF reviewers received last week prior to next week IESG review.

Regards,
Marc

________________________________
From: nvo3 [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Monday, June 02, 2014 8:59 PM
To: Thomas Narten
Cc: [email-masked]; [email-masked]; Linda Dunbar
Subject: Re: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC

Thomas,

The NVO3 Framework draft is in IETF Last Call, which isn't precisely stalled.
It is true that Linda and Lucy have raised some concerns about it.

I have not yet heard from the WG chairs or authors whether the desired changes
have been previously discussed and had consensus determined in the WG.  Linda indicated that her
comments had already been discussed on the nvo3 mailing list.  Lucy is requesting that different
technology be indicated as examples - perhaps to give a sense of future possible solutions to the
readers of the draft.

If there is WG consensus to make a few minor edits, that can be done before the
IESG review next week.  It is on the next telechat, so I would appreciate speed in
resolving the minor comment.

Regards,
Alia

On Mon, Jun 2, 2014 at 1:36 PM, Thomas Narten <[email-masked]<mailto:[email-masked]>> wrote:
I've followed the discussion on this thread and want to  go back to
something folk may have forgotten.

Thomas

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Tue, 3 Jun 2014 08:07:27 +0000

Linda,

It is a local decision to assign whatever VNI value is best suited. As I have mentioned before, it is a locally significant value that is used as a demultiplexer.
An NVE can use a VLAN ID as a locally significant value if it wants to.

Marc

________________________________
From: Linda Dunbar [mailto:[email-masked]]
Sent: Friday, May 30, 2014 5:02 PM
To: LASSERRE, MARC (MARC); Larry Kreeger (kreeger); Ken Gray (kegray)
Cc: [email-masked]; [email-masked]; IETF-Announce
Subject: RE: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC

Marc,

Questions inserted below:

From: LASSERRE, MARC (MARC) [mailto:[email-masked]]

-       Page 13 Second bullet: the text says that each VNI is automatically generated by the egress NVE. Isn't each VNI supposed to match a local virtual network (e.g. represented by VLAN)? When the same NVE acts as Ingress NVE for the attached VMs, aren't the VNI for ingress direction statically provisioned? Why need automatic egress VNI generation?

The value of the VN context identifier is a value locally significant to an NVE and does not have to match a local virtual network. It is simply used as a demultiplexer. This value can be automaticaly computed or provisioned.

[Linda]If the NVE's VAPS (VNI) are connected to VMs via Ethernet where VLAN is used, it is much easier to use locally significant VLAN. Why require egress to automatically generate local VNI value?  It would be better to change the text to:

"Each VNI value on egress NVE is either mapped to locally significant Virtual Network identifier (e.g. VLAN for Ethernet), or generated by NVA or Control Plane".

Linda

nvo3 mailing list

---

From: Alia Atlas <[email-masked]>
Date: Tue, 3 Jun 2014 09:31:21 -0400

Marc,

An updated draft would be excellent -before Thursday, preferably.

Thanks,
Alia

On Tue, Jun 3, 2014 at 4:01 AM, LASSERRE, MARC (MARC) <
[email-masked]> wrote:

>  Alia,
>
> I have replied and suggested some minor edits to address Linda and Lucy's
> comments. I have suggested to be protocol agnostic rather than giving
> specific examples in the multi-homing case.
> Some of Linda's comments have been discussed at length in the past and
> there was clear WG consensus that the framework draft addressed NVO3's
> problem.
>
> Let me know if you want me to post a revised draft based on these minor
> edits and some other suggested edits from other IETF reviewers received
> last week prior to next week IESG review.
>
> Regards,
> Marc
>
>  ------------------------------
> *From:* nvo3 [mailto:[email-masked]] * On Behalf Of *Alia Atlas
> *Sent:* Monday, June 02, 2014 8:59 PM
>
> *To:* Thomas Narten
> *Cc:* [email-masked]; [email-masked]; Linda Dunbar
> *Subject:* Re: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt>
> (Framework for DC Network Virtualization) to Informational RFC
>
>  Thomas,
>

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Thu, 5 Jun 2014 08:10:59 +0000

Alia,

As discussed, a revised -07 draft has been posted.

Thanks,
Marc

________________________________
From: nvo3 [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Tuesday, June 03, 2014 3:31 PM
To: LASSERRE, MARC (MARC)
Cc: Thomas Narten; [email-masked]; [email-masked]; Linda Dunbar
Subject: Re: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC

Marc,

Thanks,
Alia

On Tue, Jun 3, 2014 at 4:01 AM, LASSERRE, MARC (MARC) <[email-masked]<mailto:[email-masked]>> wrote:
Alia,

Regards,
Marc

________________________________
From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
Sent: Monday, June 02, 2014 8:59 PM

To: Thomas Narten
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Linda Dunbar
Subject: Re: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC

Thomas,

Regards,
Alia

Thomas