On 4/9/13 6:10 PM, "Lou Berger" <[email protected]> wrote: > > >On 4/9/2013 9:03 PM, Larry Kreeger (kreeger) wrote: >> >> >> On 4/9/13 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. >> >> LK> The immediate example that comes to mind when I hear "network >> controller" is OpenFlow > >We've had controllers for a long time. I suspect that if we worry about >every possible connotation (or similar trade name), we'll never agree on >anything.
Hey, if others agree with NV Controller, I'd love to move past this! - Larry > >BTW not that it really matters but "mapping" makes me think of DNS and >"oracle" = the obvious ;-) > >Lou > >> >>> >>> Do you think Server implies one model over the other? >> >> LK> No >> >>> >>> 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
