Policies are typically mapped to addressable identities so a bit off but not totally .. this does raise that litmus question again .. take a policy say ACL mapped to addressable identity .. this needs a lookup service over a very large flat space the kind you typically use directories and databases for .. so why isn't this metric / benchmark the litmus test rather then the protocol?
Sent from my iPhone 650 492 0794 On Apr 9, 2013, at 4:28 PM, "Larry Kreeger (kreeger)" <[email protected]> wrote: > Hi Lucy, > > So, would you consider the VN-Context to be an address? Others have also > suggested that the oracle may contain policy information as well, which I > would not consider an address mapping. > > - Larry > > From: Lucy yong <[email protected]> > Date: Tuesday, April 9, 2013 3:24 PM > To: Larry Kreeger <[email protected]>, Pat Thaler <[email protected]>, Qin > Wu <[email protected]>, "[email protected]" <[email protected]> > Subject: Re: [nvo3] NVO3 Terminology changes > > > > 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". > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
