Hi Thomas,
Please find my comments to the draft below:
_*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.
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.
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:
--------------------------------------------------------------------------------
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.
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.
--------------------------------------------------------------------------------
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.
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.
--------------------------------------------------------------------------------
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./
_*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.
The current text says:
"In L2 networks, for instance, instead of just one link-layer address
per server, the switching infrastructure may have to learn addresses of
the individual VMs (which could range in the 100s per server)."
Which is inexact in case of a PBB switching infrastructure because the
data center core bridges (underlying network) are completely unaware of
the VM addresses, they do not learn them. It is pretty much the same as
in case of an L3 underlay.
Therefore, I think it is a technology independent issue, thus the text
should not make it technology dependent.
_*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."
As it was pointed out before, the L2 protocols are just there for it,
everything is provided by the protocols and fully automatic. 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. 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.
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.
_*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.
_*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."
Note that EVPN is able to interconnect PBB network domains, thus there
is no scalability concern to be mentioned here, all are resolved by PBB
and EVPN. See, e.g.
https://datatracker.ietf.org/doc/draft-allan-l2vpn-spbm-evpn/
_*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.
_*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.
_*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.
_*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
Best regards,
János
ps:
Just though it is worth mentioning here for the people who might be
interested that there will be a tutorial on up-to-date L2 standards
given at IETF 86: http://www.ietf.org/meeting/86/tutorials/IEEE-802.html.
On 2/15/2013 10:12, Bocci, Matthew (Matthew) wrote:
This email begins a two week working group last call for
draft-ietf-nvo3-overlay-problem-statement-02.txt
Please review the draft and post any comments to the NVO3 list.
This working group last call will end on Friday 1st March 2013.
Best regards
Matthew & Benson
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
