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]
Sent: Friday, January 27, 2012 1:43 AM
To: Linda Dunbar
Cc: david.black@emc.com; dc@ietf.org; dc-bounces@ietf.org; Dinesh Dutt; kreeger@cisco.com; Murari Sridharan; 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>
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