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 protected] [mailto:[email protected]] On Behalf Of Reith,
Lothar
Sent: Monday, April 29, 2013 5:15 AM
To: Janos Farkas; Thomas Narten
Cc: [email protected]
Subject: Re: [nvo3] WG Last Call for
draft-ietf-nvo3-overlay-problem-statement-02
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:
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 station interfaces (e.g.,VNICs, which in turn are
associated with 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.
Von: [email protected]<mailto:[email protected]>
[mailto:[email protected]] Im Auftrag von János Farkas
Gesendet: Montag, 29. April 2013 10:49
An: Thomas Narten
Cc: [email protected]<mailto:[email protected]>
Betreff: Re: [nvo3] WG Last Call for
draft-ietf-nvo3-overlay-problem-statement-02
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 protected]><mailto:[email protected]> writes:
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.
<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>
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.
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:
"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."
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>
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.
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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
