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]> 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
