> -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 Larry > Kreeger (kreeger) > 发送时间: 2013年4月10日 11:17 > 收件人: Xuxiaohu; Lou Berger > 抄送: [email protected] > 主题: Re: [nvo3] NVO3 Terminology changes > > > > 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.
How about using "Tenant/VN Profile Authority" or "Tenant/VN Policy Authority" to present all other information service (e.g., ACL, policy, NV-Name to NV-Context mapping...) than the addressing mapping service? Since address mapping service is a key service, it deserves a separate and clear term, rather than a too generic term which mix all different things together, IMHO. In the latter case, you would have to clarify what's the difference between this NV controller and other controllers (e.g., OF controller and SDN controller). Best regards, Xiaohu > >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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
