Hi Janos.
=?ISO-8859-1?Q?J=E1nos_Farkas?= <[email protected]> writes:
> 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*.
OK.
Overall, I think we have converged. I agree with pretty much all your
comments. Details below.
> > 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.
> >
> <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>
OK.
> >> 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.
> > 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.
> <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.
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...
> 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).
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
> 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.
OK.
> 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].*"
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].
> 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>
Done.
> >> 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.)
> <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.*"
OK.
> 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 think VLAN here is OK. We are talking pretty generically.
> I would delete "/especially in larger data centers/" because it has no
> added value.
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
> many types ...*"
> <JF>
OK.
> >
> >> 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
> <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.
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
> just agree or disagree.
> <JF>
Agreed!
> > Thanks again for your careful review!
> You're welcome!
Hopefull, we are more-or-less converged now!
Thomas
> Best regards,
> János
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
