Subject: Re: [nvo3] You presentation on VM mobility...

From: Eric Gray <[email-masked]>
Date: Tue, 7 Aug 2012 16:04:11 -0400

Linda,

    I have some trouble understanding what you are saying.

    First, I read "when such entity is available, VID swapping can also be used" as
"when no such entity is available, VID swapping can also be used" - mostly because
I can see no possible justification for VID swapping if you are re-encapsulating using
an S-Tag, or an S-Tag/I-Tag combination.

    Not that I can see much of a justification for VID swapping in any case.  If you're
suggesting that one could side-step possible collisions in flat, C-Tagged, networks,
by constructing a "back-bone" VID mapping, that does nothing for scale issues and
is a mammoth management and OAM nightmare as well.

    Also, merely adding an S-Tag is obviously repeating the discovery process that
took place in IEEE 802.1 and eventually led to PBB.

    If we're going to re-invent the wheel, we should probably start with a reasonable
shape...

--
Eric
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, July 31, 2012 7:08 PM
To: David Allan I
Cc: [email-masked]
Subject: Re: [nvo3] You presentation on VM mobility...

David,

If there is an entity between VMs and NVE to add the S-tag, then the problem is solved. When such entity is available, VID swapping can also be used to solve the problem. So  S-tag is not the only solution.

My purpose of stating those subtle issues is to make NVo3 aware of the need to either "swap" the VID from VMs or "add" another tag when VMs send VID encoded data frames.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, July 31, 2012 3:03 PM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [nvo3] You presentation on VM mobility...

HI Linda:

Collisions in unmodified VM administered tags IMO cannot be avoided which if left along would result in the problem you describe. But that is what S-tags are for. Network administered tag value inferred from customer tag information. When mapping into a larger network (e..g S-tag->I-SID), the S-tag can still retain local significance.  Hence the only limitaton is if there is a requirement for more than 4094 VLANs at a local attachment point to the larger network. The network itself can scale to the full 2**24 tags.

cheers
Dave

________________________________
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, July 31, 2012 11:16 AM
To: David Allan I
Cc: [email-masked]
Subject: RE: You presentation on VM mobility...
David,

In the absence of VM mobility, it is easier for Overlay network to make the 12-bits VID locally significant by using core's 24 bits ID (VNID) to provide >4K's isolation.

When applications (e.g. firewall) sit on multiple subnets,  those VMs Guest OSs do send VID encoded data frames. When those VMs move, the same VID used by the VMs will appear in different NVEs, making those 12-bits VID globally significant.

Linda

From: David Allan I [mailto:[email-masked]]
Sent: Tuesday, July 31, 2012 12:45 PM
To: Linda Dunbar
Cc: [email-masked]
Subject: You presentation on VM mobility...

HI Linda:

You said that even with a 24 bit tag in the core, VM mobility would make it difficult to genuinely achieve more than 4K VLANs....

I have to admit that flies in the face of my understanding of both tagging and scaling. Could you clarify WHY you believe this to be true?

Much thanks
Dave

---

From: "Pat Thaler" <[email-masked]>
Date: Wed, 8 Aug 2012 01:35:13 +0000

Note that in IEEE 802.1Qbg VDP we provided a way to handle VM mobility and mapping a larger core tenant ID to a locally significant VLAN. Management doesn't need to set up the locally significant VLANs in this case. ("Locally significant" could be per bridge/router or per bridge/router port.)

The process is that when a VM is to be moved to a port, the physical station (e.g. the hypervisor) sends a VDP association request for the VM with a filter info field that contains the group ID (group ID is a 32-bit field that contains the identifier for the virtual LAN such as the I-CID or tenant ID)  and a null VID.

When the bridge responds to the association request, it sends back the VID to use for that traffic. The bridge maintains the mapping of VID to longer identifier and can add new local mappings as needed.

Where this is used, the VID only has local significance and I expect that the VLAN tag would be stripped on receipt by the bridge. It has no end-to-end meaning.

Regards,
Pat

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Tuesday, August 07, 2012 1:04 PM
To: Linda Dunbar; David Allan I
Cc: [email-masked]
Subject: Re: [nvo3] You presentation on VM mobility...

Linda,

--
Eric
________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Linda Dunbar
Sent: Tuesday, July 31, 2012 7:08 PM
To: David Allan I
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] You presentation on VM mobility...
David,

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of David Allan I
Sent: Tuesday, July 31, 2012 3:03 PM
To: Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] You presentation on VM mobility...

HI Linda:

cheers
Dave

________________________________
From: Linda Dunbar [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, July 31, 2012 11:16 AM
To: David Allan I
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: You presentation on VM mobility...
David,

Linda

From: David Allan I [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, July 31, 2012 12:45 PM
To: Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: You presentation on VM mobility...

HI Linda:

Much thanks
Dave