That is a very good point, Truman. I thought the same when reading several drafts, people often use 4K VLAN as the scale limitation, but the industry has already moved forward with more scalable Ethernet solutions, e.g., QinQ, and especially PBB which can support 16M (I-SID) service instances should be discussed, the reason you gave sounds like a good one, similarly, e.g. PBB's B-VLAN/S-VLAN/C-VLAN structure could be a good fit for some SP Metro-E infra networks but not so for the rather flat DC (especially overlay) structure. Then there are also different flavor of L2VPN solutions, 4K VLAN limit may or may not apply depending on the particular technology used, it would be good if each could be discussed on why or why not they fit in. e.g. some DC operators prefer not to use L2VPN solutions due to operators skill set could be a valid reason, among others?
Luyuan From: [email protected] [mailto:[email protected]] On Behalf Of Truman Boyes Sent: Tuesday, July 10, 2012 10:17 PM To: Thomas Narten Cc: John E Drake; [email protected]; [email protected] Subject: Re: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay-problem-statement-02.txt 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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
