> -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 Larry > Kreeger (kreeger) > 发送时间: 2013年4月10日 9:35 > 收件人: Lou Berger > 抄送: [email protected] > 主题: Re: [nvo3] NVO3 Terminology changes > > > 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!
Why use the "controller" term? Because it's a fashionable word? If so, why not "SDN controller":) Personally I think the term "Address Mapping Service" or "Address Mapping Authority" is fine to represent the mapping service of Overlay (inner) Address to Underlay (outer) Address. As for other mapping services like VN-Name to VN-Context, VN-Context to ACL etc, it'd better to use separate names for each of them, especially when considering the fact whether each of them is a must for NVO3 is not sure. Best regards, Xiaohu > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
