On 4/9/13 7:52 PM, "Xuxiaohu" <[email protected]> wrote:
>> -----邮件原件----- >> 发件人: [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. Having separate entities for every type of information mapping seems like overkill to me. I think we should keep it simple and have only one for now. If a particular mapping is not required, it doesn't have to be implemented, but I don't see why we need a different name for each mapping type. > >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
