Hi, when making the case that VLANS are inadequate, it may be wise to also indicate that QinQ (double tagged VLANs) as well as PBB-style approaches are also not appropriate in large scale cloud networks. While double tagged VLANS work in broadband access networks, the relationship of S,C vlan constructs in DC is not entirely flexible to cloud services.
Kind regards, Truman On Tue, Jul 10, 2012 at 8:09 PM, Thomas Narten <[email protected]> wrote: > > I would be happy to help. As the text of the two paragraphs has > > been in flux, would you please send me what you consider to be the > > latest text? > > Here is what I currently have. Paragraph's 3-4 are what we've been > going back and forth on. > > <section title="Limitations of Existing Virtual Network Models"> > <t> > Virtual networks are not new to networking. For example, > VLANs are a well known construct in the networking industry. > A VLAN is an L2 bridging construct that provides some of the > semantics of virtual networks mentioned above: a MAC address > is unique within a VLAN, but not necessarily across > VLANs. Traffic sourced within a VLAN (including broadcast > and multicast traffic) remains within the VLAN it originates > from. Traffic forwarded from one VLAN to another typically > involves router (L3) processing. The forwarding table look > up operation is keyed on {VLAN, MAC address} tuples. > </t> > > <t> > But there are problems and limitations with L2 VLANs. VLANs > are a pure L2 bridging construct and VLAN identifiers are > carried along with data frames to allow each forwarding > point to know what VLAN the frame belongs to. A VLAN today > is defined as a 12 bit number, limiting the total number of > VLANs to 4096 (though typically, this number is 4094 since 0 > and 4095 are reserved). Due to the large number of tenants > that a cloud provider might service, the 4094 VLAN limit is > often inadequate. In addition, there is often a need for > multiple VLANs per tenant, which exacerbates the issue. > </t> > > <t> > In the case of IP networks, many routers provide a virtual > routing and forwarding capability whereby a single router > conceptually supports multiple "virtual routers", each using > its own forwarding table, i.e., one tied to a specific > tenant or VPN. Each forwarding table instance is populated > separately via routing protocols, and adjacent routers > encapsulate traffic in such a way that the data plane > identifies the tenant or VPN that traffic belongs to. The > combination of virtual router functionality and data plane > separation provides address and traffic isolation for > individual tenants. > </t> > > <t> > Virtual routing and forwarding is also used on PEs as part > of providing BGP/MPLS VPN > service <xref target="RFC4364"></xref>. With BGP/MPLS VPNs, > MPLS encapsulation is used to provide tenant separation > across the transport "underlay" network between PEs. When > PEs are connected by MPLS paths, control plane protocols > (e.g., LDP <xref target="RFC5036"></xref>) are used to set > up the data path between PEs. Whether native MPLS paths or > MPLs over GRE encapsulation is > used <xref target="RFC4023"></xref>, BGP distributes the > necessary labels among PEs for tenant separation. > </t> > > <t> > There are a number of VPN approaches that provide some if > not all of the desired semantics of virtual networks. A gap > analysis will be needed to assess how well existing > approaches satisfy the requirements. > </t> > > Thomas > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
