Hey Larry,ok, got it. These paragraphs make perfect sense .. to me at least :)
A logically centralized (physically distributed ?) entity that carries any mapping .. using any resolution model push, pull, and push-pull (pubsub) depending on the mapping space, identity space, change rate, coherency, latency, acid levels .. (macs, acls, vips, nats, ucasts, mcasts healths ..) sounds good .. and hope this discussion will yield the best name for this Map job, it's a key piece in many people's view. Sent from my iPhone 650 492 0794 On Apr 9, 2013, at 5:10 PM, "Larry Kreeger (kreeger)" <[email protected]> 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]> > Date: Tuesday, April 9, 2013 4:45 PM > To: Larry Kreeger <[email protected]> > Cc: Pat Thaler <[email protected]>, "[email protected]" <[email protected]>, Qin > Wu <[email protected]>, Lucy yong <[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]> > 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
