Re: [dc] comments and suggestions to draft-narten-nv03-overlay-problem-statment-01

Hi Linda,

>You stated that “typically, it is a virtual NIC coming up that triggers 
this association”. It is not quite right. Virtual NIC, same as physical 
NIC for a non-virtualized server, usually is not aware of which >network 
segment it is attached to. For Ethernet data frames coming out from a 
traditional server (i.e. server without virtualization), the data frame is 
not tagged, i.e. not having VID associated with it. It is >the first 
switch which assign the VID for the data frame. 

Regarding "For Ethernet data frames coming out from a traditional server 
(i.e. server without virtualization), the data frame is not tagged",..." 
It is >the first switch which assign the VID for the data frame" ...

non-virtualized servers are capable of sending VLAN tagged packets. It is 
a standard feature of today'as traditional Operating Systems (NIC drivers) 
 to allow VLANs to be associated with an ethernet interface.
So a traditional non-virtualized server may send tagged and untagged 
frames.

Thanks,
Rakesh.
-=-

From:   Linda Dunbar <linda.dunbar@huawei.com>
To:     narten@rotala.raleigh.ibm.com, "david.black@emc.com" 
<david.black@emc.com>, Murari Sridharan <muraris@microsoft.com>, Dinesh 
Dutt <ddutt@cisco.com>, "kreeger@cisco.com" <kreeger@cisco.com>
Cc:     "dc@ietf.org" <dc@ietf.org>
Date:   01/26/2012 04:25 PM
Subject:        [dc] comments and suggestions to 
draft-narten-nv03-overlay-problem-statment-01
Sent by:        dc-bounces@ietf.org

Thomas, et al, 

Here are my comments to draft-narten-nv03-overlay-problem-statment-01 and 
suggested wording change:

3.1. Limitations of Existing Virtual Network Models. 

Since IEEE802.1 defined VLAN separation is mentioned, it would be 
appropriate to mention PBB’s ISID separation. 

The limitation for PBB and VLAN should include that MAC addresses can’t be 
aggregated, therefore forwarding table can be very large for large data 
centers. 

Second paragraph: Why “VLANs are a pure bridging construct while VRF is 
pure routing construct” is a problem? 

4. Network Overlays

Should add a subsection to describe Virtual Network Instance ID. 

4.x. Virtual Network Instance ID

Virtual Network Instance is for segregating traffic belonging to different 
tenants or different zones of one tenant. When a data center uses Overlay 
Network to hide hosts addresses, it is important that Virtual Network 
Instance identifier can properly represent the zones or the tenants in 
entire data center, especially when the overlay edge nodes are access 
switches, i.e. not embedded in hypervisors. 

When overlay edge nodes are access switches, the data frames before 
entering the Overlay Network or after exiting the Overlay Network might 
carry traditional VLAN-ID for proper traffic segregation. The Virtual 
Network Instance ID value carried by the Overlay Header  of the data 
frames might be 24 bits (as described in 3.2). Those VLAN-ID for data 
frames under each overlay edge node are only locally significant. Proper 
mapping has to be maintained. 

6.2 (TRILL) &6.3 (L2VPN)

It is necessary to point out that both TRILL and L2VPN carry the VLAN-ID 
embedded in the original Ethernet frames across the Overlay Network and 
the VLAN-ID maintain the same meaning in two separate L2 islands. 

When VLAN-ID tagged Ethernet frames traverse across the Overlay Network 
for Data Center, the VLAN-ID carried by Ethernet frames lose its 
significance. In another words, a different VLAN-ID might be re-assigned 
to the Ethernet frames by the Egress overlay edge. 

5.3. Associating a VNID with an endpoint. 

You stated that “typically, it is a virtual NIC coming up that triggers 
this association”. It is not quite right. Virtual NIC, same as physical 
NIC for a non-virtualized server, usually is not aware of which network 
segment it is attached to. For Ethernet data frames coming out from a 
traditional server (i.e. server without virtualization), the data frame is 
not tagged, i.e. not having VID associated with it. It is the first switch 
which assign the VID for the data frame. 

It is more accurate to say  “virtual switch” or “Hypervisor” within the 
server which can trigger the association. 

Since overlay header can be also added by first access switches (i.e. 
switches not embedded in physical servers), it is very possible that  data 
frames arriving at the overlay edge (i.e. the first access switch) is 
already VLAN tagged. Then association (or mapping) from the VLAN-Tag to 
VNID has to be operator administrated. 

Linda Dunbar
 _______________________________________________
dc mailing list
dc@ietf.org
https://www.ietf.org/mailman/listinfo/dc