On 4/9/2013 9:37 PM, Sharon wrote: > 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.
guess you never came across a route server... > > .. 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. > The composition of this WG is certainly interesting. Clearly lots of different perspectives. For example, you say mmap and I hear memory mapped I/O! Lou > > > 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
