Tom, Regarding to the limitation of existing virtual network models, we should point out that the existing models make that the network edge and client edge reside on different hardware, so the communication between two is over a wire. In NVO3, NVE and TES may be on the same physical device.
For the case of L3VPN, we should point out that CE in [RFC4364] is a network site while the TES in NVO3 may be an end system (VM). IMO: these differences may lead to a new solution or the expansion/simplification of existing solutions. So it is important to state out in the problem statement. Regards, Lucy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Narten Sent: Tuesday, July 10, 2012 7:10 PM To: John E Drake Cc: [email protected]; [email protected] Subject: Re: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay-problem-statement-02.txt > 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
