> 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
