Have to say that on this aspect I get Larry's and David's point. A server or controller turfs the problem elsewhere .. a magical controller that knows everything there is to know and consequently everything there is to do everywhere in the network..
A very non IP, almost theological view of network design. .. where as mapping owns up to the problem. Push/Pull or PubSub ALL you get at the NVO edges is just MMap. Now work with that. Sent from my iPhone 650 492 0794 On Apr 9, 2013, at 5:57 PM, Lou Berger <[email protected]> wrote: >> 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
