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

Linda,

Sometimes both can be true of the same server. A server that is can attach a VLAN-ID to data frames coming out may not be configured to do so. A large part of the problem for VLANs and overlay networks with virtualization is a control plane problem on how to get the network configuration information where it needs to be as virtual servers are moved.

5.3 doesn’t say that the virtual NIC adds the VLAN IDs to frames or that the virtual NIC itself triggers the association.

“Typically, it is a virtual NIC (the one connected to the VM)

 coming up that triggers this association. The access switch can then
   determine the VNID to be associated with this virtual NIC.”
To me this says that bringing up the virtual NIC causes something to trigger an association of a VNID with a VM. That something may not be the vNIC. The association might be made by the hypervisor as part of the installation of the virtual NIC.

For example, in the draft of IEEE 802.1Qbg, a hypervisor can use VDP (VSI Discovery and configuration Protocol) to tell the attached switch that a VSI (Virtual Station Interface, e.g. a vNIC) is coming up and ask it to create the association. VDP can either tell the attached switch what VLAN to use for the VSI or it can leave the VID field null to let the attached switch fill in the VLAN based on information such as VSI profile identifier and a 32-bit GroupID.

Regards,
Pat

From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, January 27, 2012 8:51 AM
To: Rakesh Saha
Cc: dc@ietf.org; david.black@emc.com; Dinesh Dutt; dc-bounces@ietf.org; Murari Sridharan; kreeger@cisco.com; narten@rotala.raleigh.ibm.com
Subject: Re: [dc] comments and suggestions to draft-narten-nv03-overlay-problem-statment-01

Rakesh,

I agree with you that some traditional servers can attach VLAN-ID for data frames coming out.
But many servers deployed today don’t attach VID.

Linda

From: Rakesh Saha [mailto:rsaha@us.ibm.com]<mailto:[mailto:rsaha@us.ibm.com]>
Sent: Friday, January 27, 2012 1:43 AM
To: Linda Dunbar
Cc: david.black@emc.com<mailto:david.black@emc.com>; dc@ietf.org<mailto:dc@ietf.org>; dc-bounces@ietf.org<mailto:dc-bounces@ietf.org>; Dinesh Dutt; kreeger@cisco.com<mailto:kreeger@cisco.com>; Murari Sridharan; narten@rotala.raleigh.ibm.com<mailto:narten@rotala.raleigh.ibm.com>
Subject: 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<mailto:linda.dunbar@huawei.com>>
To:        narten@rotala.raleigh.ibm.com<mailto:narten@rotala.raleigh.ibm.com>, "david.black@emc.com<mailto:david.black@emc.com>" <david.black@emc.com<mailto:david.black@emc.com>>, Murari Sridharan <muraris@microsoft.com<mailto:muraris@microsoft.com>>, Dinesh Dutt <ddutt@cisco.com<mailto:ddutt@cisco.com>>, "kreeger@cisco.com<mailto:kreeger@cisco.com>" <kreeger@cisco.com<mailto:kreeger@cisco.com>>
Cc:        "dc@ietf.org<mailto:dc@ietf.org>" <dc@ietf.org<mailto: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<mailto: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<mailto:dc@ietf.org>
https://www.ietf.org/mailman/listinfo/dc