OTOH, I think LAG implemented in OS or hypervisor software above the
NIC is on the “other side” of the network interface and hence is part
of the OS or hypervisor, independent of whether LAG is implemented in
a NIC device driver or in a device-independent fashion.
Thanks,
--David
*From:*[email protected] [mailto:[email protected]] *On Behalf
Of *David Allan I
*Sent:* Tuesday, April 23, 2013 4:59 PM
*To:* Black, David; Florian Mahr
*Cc:* [email protected]
*Subject:* Re: [nvo3] Antw: What's a TSI? It depends ...
If we can say a LAG is a form of NIC for the general case (e.g. bare
metal servers or other directly attached non-virtualized devices),
then I am happy with this.
thanks
Dave
------------------------------------------------------------------------
*From:*[email protected] [mailto:[email protected]] *On Behalf
Of *Black, David
*Sent:* Tuesday, April 23, 2013 11:50 AM
*To:* Florian Mahr
*Cc:* [email protected]
*Subject:* Re: [nvo3] Antw: What's a TSI? It depends ...
Hi Florian,
> Is there already a common understanding of the terms NIC, vNIC, TSI
> and how these terms relate to each other? I think it would be good
> to summarize the statements received so far in regard to this topic.
IMHO, yes and no J. I think the terms NIC, pNIC and vNIC are relatively
well understood:
- pNIC: Physical network interface (e.g., NIC card).
- vNIC: Virtualized version of a pNIC. My usage of this term
always refers to a virtual hardware interface presented by
a hypervisor to virtual machines (VMs), not anything higher in
a VM’s OS stack (or lower in the hypervisor).
- NIC: General term encompassing both pNICs and vNICs.
OTOH, TSI is more difficult, IMHO, as indicated by the title of this
thread ;-). Here’s my take on that, which I don’t promise to be much
more than IMHO ...
I believe the goal is that TSI:VAP cardinality be 1:1, so Dave Allen’s
observation on NIC cardinality is relevant (Dave is implicitly assuming
that the vNIC is VLAN-tagged):
> the cardinalities of vNIC to VAP does not line up. It is potentially a
> 1:N relationship.
That’s complemented by Larry Kreeger’s observation on how the mux/demux
works on the VAP side (based on VLAN tags, aka VIDs, no surprise there):
> LK> We are assuming that the physical link connecting a hypervisor
> vSwitch to an external NVE is plain old 12 bit VLAN tags, so when a
> frame arrives at the external NVE, it doesn't necessarily know what
> TSI it originated from
Beyond that, there are two complicating factors that I strongly prefer to
leave out of the definition of a TSI, based on the amount of confusion
they have caused in discussion (much heat, not much light):
- Addresses, both MAC and IP
- Link Aggregation, whether above or below the NICs (below NIC
case covers vNIC usage of aggregated pNICs).
Hence my proposal for the definition of a TSI starts from:
> When VLAN tagging is visible at the Tenant End system (i.e., NIC or
> vNIC is VLAN-tagged), but is *not* part of the L2 virtual network
> service, each VLAN is attached to a different virtual network instance
> at the NVE, so the TSI would be a <NIC, VID [VLAN ID]> pair. This is
> an important case that will occur in practice.
Restating that proposal:
- If the NIC is not VLAN-tagged, the NIC is a TSI.
- If the NIC is VLAN-tagged, the TSI is the NIC plus a VID.
I’d prefer to stop there, as that suffices when the L2 network service
provided by the nvo3 overlay is not VLAN-tagged.
If the L2 network service provided by the overlay is VLAN-tagged, the
VLAN-tagged NIC case above needs generalization. For clarity “L2 network
service provided by the overlay is VLAN-tagged” means that the
encapsulated
inner L2 frames exchanged between NVEs are VLAN-tagged. At an NVE, a VAP
for such a network sends and receives frames to/from a corresponding NIC
on multiple VLANs, not just one. The upshot is that the generalization
of TSI for this case is that the TSI is a NIC plus a set of VIDs, namely
those VIDs that the VAP is using.
That generalization complicates explaining what’s going on - my first
choice is to leave it out of the general drafts, but allow solution drafts
to explain it. Alternatively, if it needs to be explained in the general
drafts, I think it’s important to cover the “L2 network service provided
by the nvo3 overlay is not VLAN-tagged” case first (TSI is the NIC plus
a VID) before generalizing.
Does that make sense?
Thanks,
--David
p.s. Of course, once this is settled, the next question will be how it
applies to L3 network services provided by an nvo3 overlay, if at all.
For my part, I hope the L3VPN people are watching this with mild
bemusement
based on the principle that IP addresses plus routing information sort
this all out at the NVE for L3VPNs ... I hope ;-).
*From:*Florian Mahr [mailto:[email protected]]
*Sent:* Tuesday, April 23, 2013 5:34 AM
*To:* Black, David
*Cc:* [email protected]
*Subject:* Antw: [nvo3] What's a TSI? It depends ...
Hi David,
Is there already a common understanding of the terms NIC, vNIC, TSI
and how these terms relate to each other?
I think, it would be good to summarize the statements received so far
in regard to this topic.
Thanks,
Florian
>>> "Black, David" <[email protected]> 19.04.13 15.56 Uhr >>>
I would put the TSI at point B (NIC + VN), but with one important
change - IMHO, we should think in terms of VLANs at that interface,
not virtual networks. The TSI concept that we need attaches to one
virtual network instance (end system analog to the VAP). Here’s an
attempt to walk through this.
The starting point is that a physical server with an untagged NIC
attaches to exactly one virtual network instance at the NVE, therefore
the TSI is the NIC. Ditto for a virtual machine with an untagged vNIC
- that untagged vNIC is the TSI (and I like Dave Allen’s approach of
using NIC as the general term w/vNIC as a specialization).
Let’s call that vNIC-VAP communication path a “virtual link”; the next
topic is what happens when the hypervisor uses VLANs or some other
mechanism to trunk multiple untagged virtual links on a single
physical link. The TSI is still the far end of the virtual link and
the VAP is still the other end, but there is now mux/demux
functionality in both the NVE and End Device to handle this trunking.
Making VLAN tagging visible to the Tenant End System and providing it
as part of the L2 virtual network service complicates things, and
these need to be looked at independently.
When VLAN tagging is visible at the Tenant End system (i.e., NIC or
vNIC is VLAN-tagged), but is **not** part of the L2 virtual network
service, each VLAN is attached to a different virtual network instance
at the NVE, so the TSI would be a <NIC, VID [VLAN ID]> pair. This is
an important case that will occur in practice.
Adding VLAN tagging to the L2 virtual network service results in at
least a couple of possibilities. The simplest one is that the VLAN
tags from the NIC are end-to-end within the encapsulation, and we’re
back to the TSI being the NIC which is associated with one virtual
network instance via one VAP.
We might want to stop here, at least for the problem statement because
things start to get complex beyond here.
The next step is to generalize the mux/demux of virtual links onto the
End Device-NVE physical link to in effect allow VLAN tagging of those
virtual links. The result is that the VLANs used by the NIC in the
Tenant End System get grouped by virtual network that they’re attached
to (i.e., which VAP is used on the NVE), and the TSI would be a NIC
plus a set of VIDs. That’s the fully general definition with the
explicit note that the set of VIDs is often empty or contains one VID.
For example, at a vNIC, VLANs 1-6 might attach to VNI A, VLAN 7 to VNI
B, VLAN 8 to VNI C and VLANs 9-10 to VNI D.
The next wrinkle is that it’s quite possible for multiple virtual
links that are trunked onto a common physical link to want to use the
same VIDs, which will lead to having to remap VIDs as part of the
mux/demux for trunking (at both ends in full generality). I’d really
prefer not to go there in the problem statement and framework drafts ;-).
Finally, I think the use of IP addresses or MAC addresses **to
identify virtual network instances** is a mistake, and hence points C
and D are bad ideas because the desired TSI-VAP virtual link is scoped
to a virtual network instance.
Thanks,
--David
*From:*Qin Wu [mailto:[email protected]]
*Sent:* Friday, April 19, 2013 3:17 AM
*To:* Larry Kreeger (kreeger); Anoop Ghanwani
*Cc:* Black, David; [email protected]; Reith, Lothar
*Subject:* RE: [nvo3] 答复: 答 复: 答 复: 答 复: NVO3 Terminology changes
+1,
Point B is a perfect reference point. But I am not sure we only use
VNID to distinct one TSI from another, we may use combination of VNID,
MAC address and IP address.
e.g., is there any case we use two TSIs belong to the same vNIC
connect to the same VN, In this case, both TSIs use the same VNID.
Regards!
-Qin
*From:*Larry Kreeger (kreeger) [mailto:[email protected]]
*Sent:* Friday, April 19, 2013 4:41 AM
*To:* Anoop Ghanwani
*Cc:* Qin Wu; Black, David; [email protected]; Reith, Lothar
*Subject:* Re: [nvo3] 答复: 答 复: 答 复: 答 复: NVO3 Terminology changes
Hi Anoop,
What benefit do you see in defining the TSI as point C or D? Do you
agree that the TSI should directly correspond to the VAP of the NVE?
If so, it seems like point B corresponds to it.
Thanks, Larry
*From: *Anoop Ghanwani <[email protected]
<mailto:[email protected]>>
*Date: *Wednesday, April 17, 2013 8:01 PM
*To: *Larry Kreeger <[email protected] <mailto:[email protected]>>
*Cc: *Qin Wu <[email protected] <mailto:[email protected]>>, David
Black <[email protected] <mailto:[email protected]>>,
"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, "Reith, Lothar" <[email protected]
<mailto:[email protected]>>
*Subject: *Re: [nvo3] 答 复: 答复: 答复: 答复: NVO3 Terminology changes
Larry,
In reference to the figure below, I think all of them could be valid
TSIs depending on the application.
Anoop
On Wed, Apr 17, 2013 at 9:55 AM, Larry Kreeger (kreeger)
<[email protected] <mailto:[email protected]>> wrote:
Hi Qin,
A VM is one possible implementation of a Tenant System. I have not
seen anyone suggesting that a Tenant System get more granular than that.
Regarding what defines a TSI, someone could choose any branch in the
tree below to define as the TSI. I was assuming that the TSI would be
at point A below in the tree. However, point B would correspond the
the VAP. Pat had mentioned having the TSI at point D. I think if we
were to define the TSI to be either point C or point D, then it would
depend on the service being given (L2 or L3). I would prefer it to be
at point A or B.
VNIC-+-VN-+-MAC-+-IP
^ | | +-IP ...
| | |
| | +-MAC-+-IP
| | +-IP ...
| |
| +-VN-+-MAC-+-IP
| ^ | +-IP ...
| | |
| | +-MAC-+-IP
| | ^ +-IP ...
| | | ^
| | | |
A B C D
- Larry
*From: *Qin Wu <[email protected] <mailto:[email protected]>>
*Date: *Tuesday, April 16, 2013 7:14 PM
*To: *Larry Kreeger <[email protected] <mailto:[email protected]>>,
Anoop Ghanwani <[email protected] <mailto:[email protected]>>,
David Black <[email protected] <mailto:[email protected]>>
*Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, "Reith, Lothar" <[email protected]
<mailto:[email protected]>>
*Subject: *[nvo3] 答复: 答复: 答复: 答复: NVO3 Terminology changes
Hi, Larry:
Is relation between vNIC and TSI one to one or one to more?
Let me interpret what you said below,
(a)If a VM has only one vNIC, then vNIC that belongs to the VM will be
dealt with as one tenant system. Each vNIC corresponds to one TSI.
(b) If a VM has 5 vNICs and each vNIC is assigned with only one IP
address, each vNIC that belongs to the same VM will be treated as one
Tenant System. Each vNIC corresponds to one TSI. Then one VM have 5
Tenant system. Each Tenant System has one TSI.
(c) If a VM has 5 vNICs and each vNIC is assigned with 2 IP addresses,
each vNIC that belongs to the same VM will be treated as one Tenant
system, each vNIC with each IP address corresponds to one TSI. Then
one VM has 5 tenant system. Each Tenant system has 2 TSIs.
That is to say if the relation between vNIC and TSi is one to more,
then we can easy to guarantee that each TSI is associated with only
one NVE.
However if one VM is simply regarded as one tenant system and each
vNIC with multiple IP addresses belonging to one VM is treated as only
one TSI in (b)(c), take (c) as an example. when one vNIC is assigned
with multiple IP addresses and connect to multiple VNs through
multiple NVE, then one TSI has multiple IP addresses and will be
associated with multiple NVEs.
Here is two figure2, figure 1 shows one to one relation between vNIC
and TSI, figure 2 shows one to more relation between vNIC and TSI.
+---------------------+
| |
| VM (Tenant System) |
| |
+-+--------+--------+-+
| | |
| | |
| | |
+ + ...... +
vNIC1(TSI) vNIC2(TSI) vNICx(TSI)
|
|
|--------+------+
(IP add1) (IP add2) (IP addr3)
| | |
VN1 VN2 VN3
Legend: TSI -- Tenant System Interface
VN -- Virtual Network
IP add1
-- IP address1
Figure 1 One to One relation between vNIC and TSI
+---------------------+
| |
| VM (Tenant Systems)|
| |
+-+--------+--------+-+
| | |
| | |
| | |
| |
vNIC1(TS1) vNIC2(TS2) vNIC3(TS3)
|
|
+-------+------+
| | |
| | |
TSI1 TSI2 TSI3
(IP add1) (IP add2) (IP addr3)
Legend: TSI1 -- Tenant System Interface1
TS1_ Tenat System1
Figure 2 One to more relation between vNIC and TSI
I think figure 2 well match what you said below. please confirm
whether my understanding is correct.
Regards!
-Qin
*发件人**:*[email protected] <mailto:[email protected]>
[mailto:[email protected]] *代表 *Larry Kreeger (kreeger)
*发送 时间:* 2013年4月17日 7:58
*收件 人:* Anoop Ghanwani; Black, David
*抄送:* [email protected] <mailto:[email protected]>; Reith, Lothar
*主题:* Re: [nvo3] 答复: 答复: 答复: NVO3 Terminology changes
Hi Anoop,
I definitely see a TSI as belonging to a single tenant, since it is an
interface on a single tenant's system (Tenant System). My assumption
is that each TSI is associated with only one NVE, so that there is a
one to one correspondence between a TSI and a VAP on the NVE. It is
what is connected to the bottom lines in figure 4 of
http://tools.ietf.org/html/draft-ietf-nvo3-framework-02
- Larry
*From: *Anoop Ghanwani <[email protected]
<mailto:[email protected]>>
*Date: *Tuesday, April 16, 2013 4:47 PM
*To: *David Black <[email protected] <mailto:[email protected]>>
*Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, "Reith, Lothar" <[email protected]
<mailto:[email protected]>>
*Subject: *Re: [nvo3] 答复: 答复: 答复: NVO3 Terminology changes
When I think of TSI, I think of something different than a vNIC (or,
or in the case of non-virtualized systems, a NIC). Of course, it's
possible to create an implementation where a TSI is always a vNIC (or
NIC), but I don't think it is always limited to that.
It might help to clarify the following properties of a TSI:
- Can a TSI be associated with multiple NVEs?
- Does a TSI carry traffic from only one tenant or multiple tenants?
Anoop
On Tue, Apr 16, 2013 at 3:32 PM, Black, David <[email protected]
<mailto:[email protected]>> wrote:
I think this may reflect some confusion around possible meanings of
“interface”. I believe that the notion of “interface” that is desired
here corresponds to a vNIC, not a bonded set of vNICs (and likewise to
a NIC, not a bonded set of NICs). If that clarification is clear, I
think TSI would be a reasonable term.
Thanks,
--David
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] *On
Behalf Of *Reith, Lothar
*Sent:* Monday, April 15, 2013 7:18 AM
*To:* Qin Wu; Larry Kreeger (kreeger); [email protected]
<mailto:[email protected]>
*Subject:* Re: [nvo3] 答复: 答复: 答复: NVO3 Terminology changes
I believe that it is not possible to replace the term vNIC with “TSI”,
because multiple vNICs may form a single interface.
AFAIK it is common practice to use vNIC bonding (LAG) for high
availability, where two vNICs of one VM are associated with different
physical NICs of the virtualization host running the VMs. Creating a
LAG of these 2 vNICs ( NIC-Bonding) creates a single Interface of the
VM which survives the outage of one of the both physical NICs.
Lothar
*Von:*[email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] *Im
Auftrag von *Qin Wu
*Gesendet:* Montag, 15. April 2013 09:17
*An:* Larry Kreeger (kreeger); [email protected] <mailto:[email protected]>
*Betreff:* [nvo3] 答复: 答复: 答复: NVO3 Terminology changes
>>I believe one tenant system can host multiple VMs, each VM may have
multiple vNIC adapters that it uses to communicate with both the
virtual and physical networks.
>LK> A VM is one example of a tenant system…so it would not host VMs.
You may be thinking of "End Device".
>[Qin]: Not sure about that, the definition of “Tenant system” in Framework
said:
“
>Tenant System: A physical or virtual system that can play the role
>of a host, or a forwarding element such as a router, switch,
>firewall, etc. It belongs to a single tenant and connects to one or
>more VNs of that tenant.
”
>So tenant system can be a host and host one or multiple VMs on it. What
am I missing?
>LK2> I think that you are assuming that "host" is synonymous with
"Hypervisor". In the definition above, I believe the term host relates
to the more traditional definition of an internet host such as in RFC
1122.
[Qin]: So “Host” in the definition of tenant system seems misleading
since we two have different interpretation to it. I agree Hypersor or
Server or Server blade can host multiple VMs, however in the framework
document, it also said, a host can be server or server blade in the
definition of End device.
LK3> Only servers or server blades that are running hypervisors can
host multiple VMs. When we mean hypervisor we must say hypervisor
(what form factor of server it is running on is irrelevant). All
hypervisors run on servers,
[Qin]: Yes.
>but all servers are not running hypervisor software.
[Qin]: Are you saying that not all server are running hypervisor
software? If yes, I agree. If not, would you like to clarify a little bit?
Suppose one tenant A have 2 VMs resided in the server1 or hypervisor1.
Tenant B have 3 VMs resided in the server 1.
Can we say each VM belonging to the same tenant is a tenant system
LK3> Yes
or multiple VMs of each tenant sharing the same Server belong to the
same single tenant system? i.e., Tenant System A corresponding to
Tenant A contains 2 VMs. Tenant System B corresponding to Tenant B
contains 3 VMs.
LK3> No, that would be a really bad idea IMO. The fact that two VMs
happen to be running on the same server hardware is an ephemeral
thing. From one moment to the next a VM may migrate to a different
server where it becomes separated from the other VMs. Furthermore, I
see no advantage in defining a Tenant System to be a grouping of VMs
from a networking perspective since the thing that connects multiple
VMs together is the network.
[Qin]: Good point, I fully agree with you. Here is the update to
http://www.ietf.org/internet-drafts/draft-wu-nvo3-nve2nve-03.txt,
(NVO3 control plane requirement mostly for NVE to NV
Authority/Controller interface) which clears terminology confusing
based on our discussion.
_______________________________________________
nvo3 mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
