=?ISO-8859-1?Q?J=E1nos_Farkas?= <[email protected]> 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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
