LK2> I would not object to that. We had used the word "Information" to replace
the word "Address" from a different suggestion for the term "Address Mapping
Authority" since we felt the oracle would hold more than just address mappings.
[Lucy] For NVO3, this is for address mapping authority. Although the authority
process may require holding other information, the result is the address
mapping. IMO: the term of Address Mapping Authority (AMA) is fine although the
sound likes IMA.
Lucy
>2) VNIC -> Tenant System Interface
>The term VNIC is actually used in the framework document, but never defined.
>In kreeger-nvo3-hypervisor-nve-cp-01 we defined a VNIC as "A Virtual NIC that
>connects a Tenant System to a Virtual Network Instance
> (VNI)." In NVO3 (myself included) we often use VM when we are talking about
> "Tenant Systems" and talk about VMs connecting to a VNI; However, a VM can
> actually connect to multiple VNIs through multiple
>VNICs…but VNICs are very specific to Virtual Machines. If we are to use the
>more correct "Tenant System" instead of VM, we should use a more generic term
>for the interface on the tenant system itself than
>VNIC. We have suggested using "Tenant System Interface" (TSI) for this, which
>we would like to see formally defined in the Framework document and shown to
>correspond with VAPs within the NVE.
>[Qin]: Can Tenant System interface be a physical interface? If not, I suggest
>to change Tenant System virtual interface.
LK> I see no reason why a Tenant System Interface must be virtual (although it
is quite likely) - the definition in the framework for a tenant system says "A
physical or virtual system…" . I don't see that adding the word "virtual"
helps.
[Qin]: In that case, vNIC is not equivalent to Tenant System interface since
tenant system interface can be either physical interface or virtual interface.
The reason I propose such change is vNIC is virtual NIC not physical NIC,
therefore if you replace vNIC with Tenant system interface, that means Tenant
system interface only corresponds to virtual interfacel.
[pat] Even if it was always going to be virtual, Tenant System Interface is a
clear and distinct name – it’s a name, not a full description. But vNIC was
probably inconsistent as we came to an understanding that the interface could
be virtual or physical. There is no reason to restrict the tenant interfaces to
being virtual.
>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?
[pat] A tenant system doesn’t have to have anything virtual about it. A tenant
system can be a physical system with no VMs – just a plain old system connected
to the network through an NVE.
>[Qin]So VM can use multiple vNIC to connect to multiple VN. When one vNIC are
>assigned with multiple IP addresses and a single MAC addess, each vNIC can use
>multiple IP address to connect to multiple VN.
>Regarding vNIC -> Tenant System interface, I am not sure we have to replace
>vNIC with Tenant System interface since vNIC and Tenant System interface seems
>two different things and can be mapped in
>1 to 1 relation. So I think both term can be used and how they are related to
>each other can be clarified when needed.
LK> I agree that there is no need to globally replace VNIC with TSI, just as
there is no need to globally replace VM with TS. A VM (with a VNIC) is just
one common example of a TS (with a TSI). However, when being general the
TS/TSI terminology is clearer in that it covers all possible cases, not just
the common VM/VNIC case.
[Qin]: Agree, my interpretation of common case you mentioned is just a simple
case. For the case where VM has multiple vNIC, you still can tread each vNIC
as a VM that only has one vNIC and so such case is still a simple case. The
only complicated case is one vNIC connect to Multiple VN using multiple IP
addresses.
[pat] I think that we could choose to define a TSI as having a list of
associated IP addresses or as always having a single IP address. In the latter
case, a vNIC with multiple IP addresses would be modeled as multiple TSIs.
LK2> I see advantages to packaging all the MAC and IP addresses for a TSI
together when they share a common root, such as the example of a VNIC that has
one MAC but may have multiple IPs on it. It saves on coming up with a unique
TSI ID and repeating the MAC for each new IP address. It also allows
disconnect/migration messages to contain only the one TSI ID regardless of how
many IP addresses there are.
Looking forward to your feedback, Larry
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
