Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

[János Farkas <[e-mail]>]

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