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 protected] [mailto:[email protected]] On Behalf Of Linda
Dunbar
Sent: Tuesday, July 31, 2012 7:08 PM
To: David Allan I
Cc: [email protected]
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 protected] [mailto:[email protected]] On Behalf Of David
Allan I
Sent: Tuesday, July 31, 2012 3:03 PM
To: Linda Dunbar
Cc: [email protected]
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 protected]]
Sent: Tuesday, July 31, 2012 11:16 AM
To: David Allan I
Cc: [email protected]
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 protected]]
Sent: Tuesday, July 31, 2012 12:45 PM
To: Linda Dunbar
Cc: [email protected]
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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
