Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Apr 2013 11:56:28 -0400

=?ISO-8859-1?Q?J=E1nos_Farkas?= <[email-masked]> writes:

> Please find my comments to the draft below:

Thanks for the comments!

> _*Section 2 Terminology*_
> I have concerns about this section, which affect some of my later 
> comments too. I actually have trouble with all the three bullets.

> The essence of my concerns is that the this section might be interpreted 
> as no additional work has been done beyond the version of 802.1Q 
> published in 1998. (Despite of having some of the additional work listed 
> in Section 5.)

> Among other things, this implies that L2 is only capable of doing 
> "in-band virtual networks", that's why in-band and out of band are 
> defined in the draft. The terminology section further explicitly 
> emphasizes this based on the invalid implicit assumption.

> The approach used in this section is inadequate because nobody builds L2 
> data centers today based upon 1998 technology. The L2 data centers 
> deployed today use MAC-in-MAC, i.e. Provider Backbone Bridging (PBB), 
> which provides out of band virtual network overlays exactly as explained 
> and required by this document.

> Further, with PBB, B-VLANs provide the 
> transport for the out of band network virtual overlays identified by an 
> I-SID. That is, the underlying transport network (B-VLAN) is separated 
> from the overlays (e.g. I-SID), the transport does not need to know 
> about tenancy separation at all; the forwarding in the transport is only 
> done based on B-MAC and B-VID.

I agree that PBB/SPB provides benefits compared with using just
C-VIDs.

But I also believe that there are quite a few data centers that do not
use PBB or SPB. That is, we can't just assume everyone uses PBB/SPB
and hence the problems "have been solved".

> Therefore, if this document talks about any L2 solution, then it should 
> refer to up-to-date standards defined in IEEE 802.1Q-2011 - including 
> PBB MAC-in-MAC - and its recent amendments like SPB and EVB.

Fair enough.

> This document should either refer to up-to-date L2 standards, or be 
> silent on L2.

> If we elect to remove references to L2 in the terms described in Section 
> 2, then the definitions of In-Band and Overlay Networks should be as 
> follows:

Let's leave in the references, but clean them up.

> Or - if we want to keep the L2 references - then the section should 
> either be updated, or an explicit statement should be made clarifying 
> the intent that this document does not aim to include analysis of more 
> up-to-date deployments based on IEEE 802.1Q-2011. I would point out that 
> this will - in effect - be the same as saying that this document is 
> intentionally invalid with respect to analysis and comments made with 
> respect to L2 technologies.

> To update the text related to VLANs, the terms should be defined as follows:
> --------------------------------------------------------------------------------
> In-Band Virtual Network:  A Virtual Network that separates tenant 
> traffic without hiding tenant forwarding information from the physical 
> infrastructure.  The Tenant System may also retain visibility of a 
> tenant within the underlying physical infrastructure.  IEEE 802.1Q-1998 
> networks only using C-VIDs are an example of an in-band Virtual Network.

Works for me.

> Overlay Virtual Network:  A Virtual Network in which the separation of 
> tenants is hidden from the underlying physical infrastructure. That is, 
> the underlying transport network does not need to know about tenancy 
> separation to correctly forward traffic. IEEE 802.1 Provider Backbone 
> Bridge (PBB) networks are an example for Overlay Virtual Networks. The 
> underlying transport network is provided by Backbone VLANs (B-VLAN) 
> implementing the forwarding based on B-MAC and B-VID, therefore, the 
> transport is unaware of the tenancy separation provided by an Overlay, 
> e.g. by the 24-bit I-SID Overlays.

How about:

 Overlay Virtual Network: A Virtual Network in which the separation of
 tenants is hidden from the underlying physical infrastructure. That
 is, the underlying transport network does not need to know about
 tenancy separation to correctly forward traffic. IEEE 802.1 Provider
 Backbone Bridging (PBB) is an example of an L2 Overlay Network. PBB
 uses MAC-in-MAC encapsulation and the underlying transport network
 forwards traffic using only the B-MAC and B-VID in the outer header.
 The underlay transport network is unaware of the tenancy separation
 provided by, for example, a 24-bit I-SID.

> --------------------------------------------------------------------------------

> The bullet defining VLANs should either be deleted, or should refer to 
> IEEE 802.1Q-2011 as the most up-to-date authoritative definition of the 
> term.

> /My preference is to update the text to refer correctly to IEEE 
> 802.1Q-2011 for all three terms./

How about:

   VLANs: An informal term used in this document to refer to IEEE
	  802.1Q networks using C-VIDs (as defined in IEEE
	  802.1Q-2011) at the network edge.  C-VIDs are generally
	  associated with end stations (e.g., VMs). Within an IEEE
	  802.1Q-2011 network, other tags may be used as well, but
	  such usage is generally transparent to the network edge.

> _*Section 3.3*__**__*Inadequate Forwarding Table Sizes*_
> A sentence should be updated to:
> "For instance, instead of just one address per server, the network 
> infrastructure may have to learn addresses of the individual VMs (which 
> could range in the 100s per server)."

> This is a generic issue, not specific to routing or bridging. That is, 
> we used to have a server with a single (or very few) address(es) and now 
> we have orders of magnitude more addresses instead due to the VMs. 
> Address really holds for IP and MAC address here, VMs (may) have
> both.

OK. I will make the suggested change.

> _*Section 3.4.  Need to Decouple Logical and Physical Configuration*_
> I fully agree with the point made in the section title, However, I still 
> find the text on VLANs inexact and unnecessary here.

> Please remove:
> "In networks using VLANs, moving servers elsewhere in the network may 
> require expanding the scope of the VLAN beyond its original boundaries.  
> While this can be done, it requires potentially complex network 
> configuration changes and can conflict with the desire to bound the size 
> of broadcast domains, especially in larger data centers.  In addition, 
> when VMs migrate, the physical network (e.g., access lists) may need to 
> be reconfigured which can be time consuming and error prone."

> If you want to keep it then it should be made generic as it inherently 
> is a generic problem. If a server is a member of a (virtual) network, 
> and the server is then moved to another location then the new location 
> has to be configured as part of the (virtual) network the server is 
> member of. A generalized version might look like e.g.:
> "Moving servers elsewhere in a network may require expanding the scope 
> of the network beyond its original boundaries.  While this can be done, 
> it requires potentially complex network configuration changes. The 
> configuration burden would increase, when VMs migrate, which can be time 
> consuming and error prone."

I think we should leave the L2 text in. This is a real issue in DC
networks today. IMO, the text is more clear when using VLANs as an
example. (More below.)

> As it was pointed out before, the L2 protocols are just there for it, 
> everything is provided by the protocols and fully automatic.

I disagree with this. (More below.)

> VDP provides all the information associated with VM migration, based
> on which the virtual overlay(s) the VM is member of can be expanded
> automatically at Network Virtual Edges.

VDP is barely deployed today. There are few products supporting VDP
and port profiles.  It is not accurate to imply that VDP solves this
problem today. 

> SPBM controlling the underlying PBB network also does its job
> automatically, i.e. provides the connectivity for the overlay. This
> should be described if the intention is to talk about L2.

Likewise, SPBM is also not widely deployed today. Indeed, I am aware
of very few SPBM shipping products. I think it is fair to say that
SPMB has not reached critical mass within industry. It is also unclear
to me when/if that will change. Consequently, I think it would be
misleading to suggest that VDP/SPBM is what people do today and that
they adequately solve the problem.

Hence, I do think we need to leave the above text in place with
references to L2

> Later in the same section (Need to Decouple Logical and Physical 
> Configuration)

> Please remove:
> "or when the expansion requires that the scope of the underlying L2 VLAN 
> expand beyond its original pod boundary."

> If one has a multi-pod L2 data center, then the L2 network spans over 
> all pods. It is not difficult at all to expand the B-VLAN in order to 
> get multiple pods involved.

Not necessarily. But I think you are now also assuming PBB/SPB is in
use, which per above is not an assumption I think we can make.

> _*4.1.  Overview of Network Overlays*_
> I'd prefer to just have:
> "Because an overlay network is used, a VM can now be located anywhere in 
> the data center that the overlay reaches."
> i.e. remove:
> "without regards to traditional constraints imposed by the underlay 
> network such as the L2 VLAN scope, or the IP subnet scope" as I do not 
> find it neither useful nor necessary.

I think it's worth keeping this in. It is these "traditional
constraints" that make moving VMs challenging today.

> _*Section 5.2.  BGP/MPLS Ethernet VPNs*_
> Please update this sentence:
> "This means that the limit of 4096 VLANs is associated with an 
> individual tenant service edge, enabling a much higher level of 
> scalability."

> to:
> "This means that any customer site VLAN based limitation is associated 
> with an individual tenant service edge, enabling a much higher level of 
> scalability."

I'm fine with this proposed change. (But defer to others who provided
the original text.)

> _*Section 5.5 ARMD*_
> Please delete:
> "an overlay approach may also push some of the L2 scaling concerns 
> (e.g., excessive flooding) to the IP level (flooding via IP multicast)."
> L2 scalability issues have been resolved at L2 by IEEE 802.1 standards 
> years ago.

I'm OK with taking out the above, though I'm not sure everyone would
agree with the latter justification.

> _*Section 5.10*__*VDP*_
> Maybe it would be good to locate the IEEE 802.1 sections back-to-back as 
> they sort of refer to each other; e.g. move Section 5.10 VDP right after 
> Section 5.4 SPB.

Happy to do this.

> _*Section 6 Further Work*_
> Delete this section please. I do not see the need for it. Work items 
> have been already identified by earlier sections. Furthermore, I do not 
> find useful to talk about further work in an approved and published 
> standard.

I'm OK with removing this section.

> _*Section 11  Informative References*_
> I'd make some updates:
> [I-D.ietf-l2vpn-evpn]
>                Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F.,
>                Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN",
>                draft-ietf-l2vpn-evpn-03 (work in progress), February 2013.

> [Qbg]
> IEEE 802.1Qbg, "IEEE standard for local and metropolitan area networks: 
> Media access control (MAC) bridges and virtual bridged local area 
> networks -- Amendment 21: Edge virtual bridging," July 2012. 
> http://standards.ieee.org/getieee802/download/802.1Qbg-2012.pdf

> [SPB]
> IEEE 802.1aq, "IEEE standard for local and metropolitan area networks: 
> Media access control (MAC) bridges and virtual bridged local area 
> networks -- Amendment 20: Shortest path bridging," June 2012. 
> http://standards.ieee.org/getieee802/download/802.1aq-2012.pdf

> and I'd add:
> [802.1Q] or [Q]
> IEEE 802.1Q-2011, "IEEE standard for local and metropolitan area 
> networks: Media access control (MAC) bridges and virtual bridged local 
> area networks," August 2011. 
> http://standards.ieee.org/getieee802/download/802.1Q-2011.pdf

Will update the above.

Thanks again for your careful review!

Thomas

> Best regards,
> János

---

From: János Farkas <[email-masked]>
Date: Mon, 29 Apr 2013 10:49:27 +0200

Hi Thomas,

Thank you for your feedback!

I'm only keeping items still under discussion in this mail in order to 
make it easier to read. (It is a quite long discussion.)
My current reply is in <JF> brackets.
I suggest a couple of further updates, which involve 
deletion/replacement of /current text/ with *new text*.

Thomas Narten wrote:
> <[email-masked]> writes:
>

<JF>
Looks good.
A minor comment: "*I-SID overlays*"is more accurate, because multiple 
groups of entities may be separated from each other. Thus, the end of 
the paragraph should look like: "*for example, 24-bit I-SID overlays.*"
<JF>

> 	  such usage is generally transparent to the network edge.

<JF>
I still think that there is no need to have text in Section 2 for 
explaining VLANs. Section 5.3 provides a more detailed description, 
which I think is enough for this document. I think the best would be 
just to refer to Section 5.3 at the first occurrence of VLAN in the 
document; and do not add any explanation to Section 2.

If I understand it right, then your intention with the VLAN bullet in 
Section 2 is to explain that the term "VLAN" means "C-VLAN" in the core 
of the document (Sections 3 and 4). In order to achieve that, I think it 
would be much cleaner to use "C-VLAN" instead of "VLAN" in Sections 3 
and 4, which would make it explicit thus avoid any ambiguity. Referring 
to Section 5.3 at the first occurrence of C-VLAN would then guide the 
reader to get more information on VLANs.

However, if you really want to have a VLAN bullet in Section 2, then it 
has to be clear and unambiguous and it should in fact be a C-VLAN bullet 
for the above reasons. I'm making a try to help you on that if you 
really want to go for it:
"*C-VLAN: This document refers to C-VLAN as implemented by many routers, 
i.e. a L2 virtual network identified by a C-VID. Section 5.3 provides 
more details on VLANs defined by [802.1Q].*"

Anyway, I highly recommend replacing "VLAN" and "L2 VLAN" with "C-VLAN" 
in the following places:
1) Section 3.2, last paragraph: replace "/the VLAN configured/" with 
"*the C-VLAN configured*"
2) Section 3.4, last paragraph: replace "/underlying L2 VLAN/" with 
"*underlying C-VLAN*"
3) Section 4.1, 10th paragraph (starting with "A key aspect of 
overlays"): replace "/the L2 VLAN scope/" with "*the C-VLAN scope*"
<JF>

> networks today. IMO, the text is more clear when using VLANs as an

<JF>
If you want to have text on the network expansion problem, then you should
replace
"/In networks using VLANs, moving servers elsewhere in the network may 
require expanding the scope of the VLAN beyond its original boundaries. 
While this can be done, it requires potentially complex network 
configuration changes and can conflict with the desire to bound the size 
of broadcast domains, especially in larger data centers./"
with
"*In networks of many types (e.g. -- IP subnets, MPLS VPNs, VLANs) 
moving servers may require expanding the scope of a portion of the 
network (subnet, VPN, VLAN) beyond its original boundaries. While this 
can be done, it requires potentially complex network configuration 
changes and may (in some cases -- e.g. -- a VLAN or L2VPN) conflict with 
a desire to bound the size of broadcast domains.*"

My point is that expanding a (virtual) network is a generic networking 
problem, therefore, should not be made as if it was only the attribute 
of VLANs. The generic problem is definitely there in any network if one 
does not use protocols designed to solve the problem. If you want to 
keep the text and do not want to generalize it along my suggestion in 
the previous mail, then you should add further examples to make it 
correct. IP is definitely used in data centers, so it should be there. 
MPLS should be there too as it was at least proposed to be used (see 
e.g." http://tools.ietf.org/id/draft-sajassi-nvo3-evpn-overlay-01.txt).
/Note that I suggested VLAN instead of C-VLAN here because it is about 
networking in general. It is also valid for C-VLAN, so you may use that 
instead if you prefer./

I would delete "/especially in larger data centers/" because it has no 
added value.

I'd make a separate paragraph out of it starting with "*In networks of 
many types ...*"
<JF>

> Hence, I do think we need to leave the above text in place with

<JF>
See my point to the given text above.

I strongly disagree with your statements on VDP and SPBM because they 
adequately solve the problems they address.
However, as it does not seem directly affecting text in the draft we may 
just agree or disagree.
<JF>

> Thanks again for your careful review! 

You're welcome!

Best regards,
János

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 29 Apr 2013 09:15:07 +0000

Please correct below definition as follows:

Please replace the term "end stations, (e.g. VMs) by "end station interfaces (e.g.,VNICs, which in turn are associated with VMs"

Resulting in the following:

          associated with end station interfaces (e.g.,VNICs, which in turn are associated with VMs). Within an IEEE

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von János Farkas
Gesendet: Montag, 29. April 2013 10:49
An: Thomas Narten
Cc: [email-masked]
Betreff: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Hi Thomas,

I'm only keeping items still under discussion in this mail in order to make it easier to read. (It is a quite long discussion.)
My current reply is in <JF> brackets.
I suggest a couple of further updates, which involve deletion/replacement of current text with new text.

Thomas Narten wrote:

<[email-masked]><mailto:[email-masked]> writes:

How about:

<JF>
Looks good.
A minor comment: "I-SID overlays" is more accurate, because multiple groups of entities may be separated from each other. Thus, the end of the paragraph should look like: "for example, 24-bit I-SID overlays."
<JF>

term.

How about:

<JF>
I still think that there is no need to have text in Section 2 for explaining VLANs. Section 5.3 provides a more detailed description, which I think is enough for this document. I think the best would be just to refer to Section 5.3 at the first occurrence of VLAN in the document; and do not add any explanation to Section 2.

If I understand it right, then your intention with the VLAN bullet in Section 2 is to explain that the term "VLAN" means "C-VLAN" in the core of the document (Sections 3 and 4). In order to achieve that, I think it would be much cleaner to use "C-VLAN" instead of "VLAN" in Sections 3 and 4, which would make it explicit thus avoid any ambiguity. Referring to Section 5.3 at the first occurrence of C-VLAN would then guide the reader to get more information on VLANs.

However, if you really want to have a VLAN bullet in Section 2, then it has to be clear and unambiguous and it should in fact be a C-VLAN bullet for the above reasons. I'm making a try to help you on that if you really want to go for it:
"C-VLAN: This document refers to C-VLAN as implemented by many routers, i.e. a L2 virtual network identified by a C-VID. Section 5.3 provides more details on VLANs defined by [802.1Q]."

Anyway, I highly recommend replacing "VLAN" and "L2 VLAN" with "C-VLAN" in the following places:
1) Section 3.2, last paragraph: replace "the VLAN configured" with "the C-VLAN configured"
2) Section 3.4, last paragraph: replace "underlying L2 VLAN" with "underlying C-VLAN"
3) Section 4.1, 10th paragraph (starting with "A key aspect of overlays"): replace "the L2 VLAN scope" with "the C-VLAN scope"
<JF>

Please remove:

example. (More below.)

<JF>
If you want to have text on the network expansion problem, then you should
replace
"In networks using VLANs, moving servers elsewhere in the network may require expanding the scope of the VLAN beyond its original boundaries. While this can be done, it requires potentially complex network configuration changes and can conflict with the desire to bound the size of broadcast domains, especially in larger data centers."
with
"In networks of many types (e.g. - IP subnets, MPLS VPNs, VLANs) moving servers may require expanding the scope of a portion of the network (subnet, VPN, VLAN) beyond its original boundaries. While this can be done, it requires potentially complex network configuration changes and may (in some cases - e.g. - a VLAN or L2VPN) conflict with a desire to bound the size of broadcast domains."

My point is that expanding a (virtual) network is a generic networking problem, therefore, should not be made as if it was only the attribute of VLANs. The generic problem is definitely there in any network if one does not use protocols designed to solve the problem. If you want to keep the text and do not want to generalize it along my suggestion in the previous mail, then you should add further examples to make it correct. IP is definitely used in data centers, so it should be there. MPLS should be there too as it was at least proposed to be used (see e.g." http://tools.ietf.org/id/draft-sajassi-nvo3-evpn-overlay-01.txt).
/Note that I suggested VLAN instead of C-VLAN here because it is about networking in general. It is also valid for C-VLAN, so you may use that instead if you prefer./

I would delete "especially in larger data centers" because it has no added value.

I'd make a separate paragraph out of it starting with "In networks of many types ..."
<JF>

problem today.

references to L2

<JF>

I strongly disagree with your statements on VDP and SPBM because they adequately solve the problems they address.
However, as it does not seem directly affecting text in the draft we may just agree or disagree.
<JF>

You're welcome!

Best regards,
János

---

From: Eric Gray <[email-masked]>
Date: Mon, 29 Apr 2013 18:37:52 +0000

Lothar,

                Your reply below appears to have missed the fact that this is a proposed definition for
"C-VLAN" - which is the specific type of VLAN that uses C-VIDs to identify individual VLANs.  It
is - I believe - essential that we are more precise in the use of this terminology as we do use
the term "VLAN" in several places to mean "VLAN as defined in IEEE 802.1Q-2011" (a much
bigger concept.

                If we are not clear in using the correct terms in the right places, then we will be making
technically incorrect assertions about various types of Virtual LANs in different parts of the draft.

--
Eric

From: [email-masked] [mailto:[email-masked]] On Behalf Of Reith, Lothar
Sent: Monday, April 29, 2013 5:15 AM
To: Janos Farkas; Thomas Narten
Cc: [email-masked]
Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Im Auftrag von János Farkas
Gesendet: Montag, 29. April 2013 10:49
An: Thomas Narten
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Hi Thomas,

Thomas Narten wrote:

How about:

<JF>
Looks good.

term.

How about:

<JF>

Please remove:

example. (More below.)

<JF>

problem today.

references to L2

<JF>

You're welcome!

Best regards,
János

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 29 Apr 2013 20:01:41 +0000

Hi Eric,

your point should have been addressed to Janos, who came up with the VLAN definition.

I just wanted to point to the fact, that the term  "end station" may be ambiguous regarding the layer.

I realize that even when the VM is dual attached to the network via two end station interfaces (for example two VNICs bound to one MAC-Layer and one  L2-SAP interfacing upwards in the stack to one  layer 3 interface interfacing from the layer 3 layer network downwards in the stack towards the L2-SAP) the VLAN-ID still identifies the end station in the upward direction (from network to VM),however, in the  downward direction  from VM to network there would be one layer 3 interface interfacing with one L2-SAP that may be associated with two L1-interfaces of the dual attachment (two vNIC ports forming a LAG).

The reason for my comment was to be able to accommodate this situation of a dual attached VM, given that the application in the VM may initiate a LAG because the application is not aware that the NICs which it sees are not physical NICs but only virtual NICs.

Lothar

Von: Eric Gray [mailto:[email-masked]]
Gesendet: Montag, 29. April 2013 20:38
An: Reith, Lothar; Janos Farkas; Thomas Narten
Cc: [email-masked]
Betreff: RE: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Lothar,

--
Eric

Hi Thomas,

Thomas Narten wrote:

How about:

<JF>
Looks good.

term.

How about:

<JF>

Please remove:

example. (More below.)

<JF>

problem today.

references to L2

<JF>

You're welcome!

Best regards,
János

---

From: Eric Gray <[email-masked]>
Date: Mon, 29 Apr 2013 20:18:24 +0000

Lothar,

                Sorry, but you're confused, it seems.  I can easily understand why that is because it can be such
a trial to figure out who said what in these "threaded" discussions.

                The definition provided by Janos (in Green, below, as it was originally from Janos) is for C-VLAN.

                I said nothing about your point about "end stations" - I just pointed out that you were trying to
define VLAN as "802.1Q networks using C-VIDs."

                Hence I was correct in addressing my point to you.  You responded to the definition offered by
Thomas in an earlier iteration of the discussion, hence you were inadvertently taking the discussion back
a step.

                In addition to being completely incorrect, your definition leads to ambiguity when a reader gets
to later sections in the draft where we use "VLAN" to mean "VLAN as defined by IEEE 802.1Q-2011."

                If you read Janos' comment more closely, you will see that - not only does he define "C-VLAN",
but he also describes exactly those instances where we currently use "VLAN" and should use "C-VLAN."

--
Eric

From: Reith, Lothar [mailto:[email-masked]]
Sent: Monday, April 29, 2013 4:02 PM
To: Eric Gray; Janos Farkas; Thomas Narten
Cc: [email-masked]
Subject: AW: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02
Importance: High

Hi Eric,

Lothar

Lothar,

--
Eric

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Reith, Lothar

Hi Thomas,

Thomas Narten wrote:

How about:

<JF>
Looks good.

term.

How about:

<JF>

Please remove:

example. (More below.)

<JF>

problem today.

references to L2

<JF>

You're welcome!

Best regards,
János

---

From: Eric Gray <[email-masked]>
Date: Mon, 29 Apr 2013 21:03:39 +0000

Lothar,

                For examples of the inconsistent use of the term "VLAN", see sections 5.2 and 5.3 - where we're
clearly using "VLAN' to mean any/all kinds of VLANs defined by IEEE 802.1Q-2011.  In section 5.3, this is
very explicit and conflicts with the way we have currently "defined" VLAN in the terminology section.

                Also, there are a couple of places in section 3.4 where we use the term VLAN and the "C-VID"
limitation may or may not apply.

                The choice to use the term "C-VLAN" was apparently made before and I think we missed it with
all of the many other suggestions being made at the time.  At the time, it may very well have been the
impression that many had that we would be globally replacing the term "VLAN" with the term "C-VLAN"
- which may have been viewed at the time as possibly one of the less important changes we might make.

                However, as the change proposed by Janos hopefully makes clear, this is not a global "search
and replace" - but a selective replacement in order to improve the accuracy of the draft text.

                Whatever definition we use, will likely point to IEEE 802.1Q-2011, so it not necessary for us to
explicitly define VLAN.  Moreover, it has become apparent that any attempt to do so that is - in any
way - inconsistent with the definition provided in IEEE 802.1Q will become a "comment magnet" and
we don't need any more of those than we must have.

                I have no opinion about your proposal to provide an example of what might be meant in the
NVO3 context by "end station interface" - and therefore no strong objection.  I would caution that we
may not want to introduce terminology that may be undergoing change as a result of other discussion
on the NVO3 mailing list - particularly in the form of an example.

                I cannot speak for others on this topic and - since my opinion on this is essentially "no opinion"
- I did not comment on this part of your reply earlier.

                I would ask that people not discuss this comment overly much based on the previous VLAN
definition - unless they explicitly object to the definition proposed by Janos - as that will only tend to
promote cyclic argument and confusion.

--
Eric

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Monday, April 29, 2013 4:18 PM
To: Reith, Lothar; Janos Farkas; Thomas Narten
Cc: [email-masked]
Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Lothar,

--
Eric

Hi Eric,

Lothar

Lothar,

--
Eric

Hi Thomas,

Thomas Narten wrote:

How about:

<JF>
Looks good.

term.

How about:

<JF>

Please remove:

example. (More below.)

<JF>

problem today.

references to L2

<JF>

You're welcome!

Best regards,
János

---

From: "Reith, Lothar" <[email-masked]>
Date: Tue, 30 Apr 2013 08:55:58 +0000

Hi Eric,

I agree to suspend the discussion here. I will follow up the point while reviewing  draft-kompella-nvo3-server2nve-02 which has been published today.

draft-kompella-nvo3-server2nve-02 contains the following two definitions of interest:

      VM: Virtual Machine (same as Virtual Station)
      VSI: Virtual Station Interface

Hopefully it can be clarified in that context. Otherwise I may resume discussion at a later point.

Lothar

Von: Eric Gray [mailto:[email-masked]]
Gesendet: Montag, 29. April 2013 23:04
An: Reith, Lothar
Cc: [email-masked]; Janos Farkas; Thomas Narten
Betreff: RE: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Lothar,

--
Eric

Lothar,

--
Eric

Hi Eric,

Lothar

Lothar,

--
Eric

Hi Thomas,

Thomas Narten wrote:

How about:

<JF>
Looks good.

term.

How about:

<JF>

Please remove:

example. (More below.)

<JF>

problem today.

references to L2

<JF>

You're welcome!

Best regards,
János

---

From: Thomas Narten <[email-masked]>
Date: Tue, 30 Apr 2013 14:42:45 -0400

Hi Janos.

> deletion/replacement of /current text/ with *new text*.

OK.

Overall, I think we have converged. I agree with pretty much all your
comments. Details below.

> the paragraph should look like: "*for example, 24-bit I-SID overlays.*"

OK.

> document; and do not add any explanation to Section 2.

Section 2 is terminology. We use "VLAN" throughout the document. It
seems reasonable to me this defintion here. I think it would be less clear
to the average reader to have a forward reference to (effectively) the
end of the document.

That said...

> of the document (Sections 3 and 4).

To be clear, this WG has used the term VLAN fairly loosely for some
time. Look at all the NVO3 documents. They all use "VLAN", in some
cases in ways where C-VIDs is arguably the more precise terminology.

In the back-and-forth we've had (which, to be clear, I appreciate!!),
I've come to understand that in many (most?) cases where the term VLAN
is used, it really does effectively mean a VLAN implemented using
C-VIDs. In the case of server virtualization (a big focus of this WG)
for instance, when talking about VLANs, it is almost always the case
that what is meant is the VLANs associated with the VMs -- i.e,
C-VIDS. the other VIDS (S-VIDs, I-SIDs, etc.)  that are available on
the network are just not something servers know about (or need to).

You are saying we should be more precise and use the term C-VLAN
rather than VLAN where appropriate. I think that makes sense.

> In order to achieve that, I think it 

OK.

> more details on VLANs defined by [802.1Q].*"

Here is proposed text (it includes some wording from the previous
iteration of this text):

  C-VLAN: This document refers to C-VLAN as implemented by many
      routers, i.e., an L2 virtual network identified by a C-VID.
      C-VIDs are generally associated with end stations (e.g., VMs) at
      the network edge. Within an IEEE 802.1Q-2011 network, other tags
      may be used as well, but such usage is generally transparent to
      the network edge. Section 5.3 provides more details on VLANs
      defined by [802.1Q].

> overlays"): replace "/the L2 VLAN scope/" with "*the C-VLAN scope*"

Done.

> a desire to bound the size of broadcast domains.*"

OK.

> networking in general. It is also valid for C-VLAN, so you may use that 

I think VLAN here is OK. We are talking pretty generically. 

> I would delete "/especially in larger data centers/" because it has no 

I deleted it, but would argue that it is mainly in larger networks
where limiting the scope becomes a desire.

> I'd make a separate paragraph out of it starting with "*In networks of 

OK.

> adequately solve the problems they address.

Do you disagree with my statement that they  are not widely
deployed/available? Or some other part?

> However, as it does not seem directly affecting text in the draft we may 

Agreed!

> You're welcome!

Hopefull, we are more-or-less converged now!

Thomas

---

From: "Pat Thaler" <[email-masked]>
Date: Tue, 30 Apr 2013 21:40:12 +0000

Hi Lothar,

Actually, if I'm following the thread correctly, the VLAN definition that used "end station" was from Thomas. Janos suggested a very brief definition of C-VLAN that references IEEE 802.1Q.

An end station or end station interface isn't "identified by a VLAN-ID". A C-VID identifies a virtual network. MAC address plus C-VID may identify an MSAP (MAC service access point). If the MAC address is globally scoped, the MAC address alone identifies the MSAP, but a MAC address may be a local address and only unique within a VLAN or set of VLANs and in that case it is the MAC address, C-VID pair that identifies the MSAP.

I agree with Janos that it would be best to use C-VLAN rather than VLANs when the document means C-VLAN and to reference IEEE 802.1Q for C-VLAN definition.

By the way, the short definition of a VLAN in IEEE 802.1Q-2011 is:
The closure of a set of MAC SAPs such that a data request in one MAC SAP in the set is
expected to result in a data indication in another MAC SAP in the set.

Regards,
Pat

From: [email-masked] [mailto:[email-masked]] On Behalf Of Reith, Lothar
Sent: Monday, April 29, 2013 1:02 PM
To: Eric Gray; Janos Farkas; Thomas Narten
Cc: [email-masked]
Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Hi Eric,

Lothar

Lothar,

--
Eric

Hi Thomas,

Thomas Narten wrote:

How about:

<JF>
Looks good.

term.

How about:

<JF>

Please remove:

example. (More below.)

<JF>

problem today.

references to L2

<JF>

You're welcome!

Best regards,
János