> where a > Controller/Orchestrator implies an intelligent push to only the NVEs > that need it.
Humm, where does this implication come from? I don't see that connotation. Do you think Server implies one model over the other? Lou On 4/9/2013 8:10 PM, Larry Kreeger (kreeger) wrote: > Hi Sharon, > > The goal is to have a name for a "logically centralized" entity (oracle) > that can carry mapping information for the NVEs, such as VN-Name to > VN-Context, Overlay (inner) Address to Underlay (outer) Address. People > start getting uncomfortable when they see a name that implies a > particular interaction model between the NVE and the oracle. I think it > all comes down to push vs pull and the scope of how much information is > pushed/pulled to the NVE and when. > > To me a Directory Service implies a directory lookup (pull), where a > Controller/Orchestrator implies an intelligent push to only the NVEs > that need it. An "authority" does not imply either model to me (similar > to oracle). So, for me the litmus test is whether the name implies push > or pull. I think David brought up BGP as an example of a protocol that > is more of a push and therefore doesn't fit into the pull model implied > by a directory, nor in my opinion the added intelligence of a > controller/orchestrator. > > - Larry > > From: Sharon <[email protected] <mailto:[email protected]>> > Date: Tuesday, April 9, 2013 4:45 PM > To: Larry Kreeger <[email protected] <mailto:[email protected]>> > Cc: Pat Thaler <[email protected] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, Qin Wu <[email protected] > <mailto:[email protected]>>, Lucy yong <[email protected] > <mailto:[email protected]>> > Subject: Re: [nvo3] NVO3 Terminology changes > > 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] > <mailto:[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] <mailto:[email protected]>> >> Date: Tuesday, April 9, 2013 3:24 PM >> To: Larry Kreeger <[email protected] <mailto:[email protected]>>, Pat >> Thaler <[email protected] <mailto:[email protected]>>, Qin Wu >> <[email protected] <mailto:[email protected]>>, "[email protected] >> <mailto:[email protected]>" <[email protected] <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
