Agree. The term should be general enough to cover all cases. Luyuan From: <Black>, David <[email protected]<mailto:[email protected]>> Date: Tuesday, April 9, 2013 5:37 PM To: Sharon <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] NVO3 Terminology changes
I believe that BGP is among the possible ways to implement this service. I think that “directory” is not a good characterization of BGP. Hence “directory” does not appear to be a good word to use as part of the replacement of the “Oracle” term. Thanks, --David From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Sharon Sent: Tuesday, April 09, 2013 2:58 PM To: Larry Kreeger (kreeger) Cc: [email protected]<mailto:[email protected]> Subject: Re: [nvo3] NVO3 Terminology changes Just a light content comment (summary does reflect the meeting content in my view) Seems perfectly logical that an Overlay will need a method of sharing global information per entities "beyond" the Underlay, and that it's "Oracle-Like" mechanism e.g you ask it questions and get answers .. even in Delphi the Oracle didn't pre guess questions ... .. Also mapping /IMA seems a perfectly reasonable reduction of what this service offers, and distributed directory captures how it offers it - after all if there is an Overlay there is also an Underlay - a perfectly functioning network to anchor such s mechanism .. What's not clear is why insisting on BGP if there is a clear claim BGP is not a directory oriented protocol ? Sent from my iPhone 650 492 0794 On Apr 8, 2013, at 6:12 PM, "Larry Kreeger (kreeger)" <[email protected]<mailto:[email protected]>> wrote: At the NVO3 WG meeting in Orlando, I brought up some suggestions for terminology changes/additions and had an AI to bring this to the list…so here goes. I would prefer to see constructive suggestions in responses. In other words, please suggest something better if you object to these. 1) Oracle -> Information Mapping Authority Stewart mentioned that he has copyright concerns with using the term "oracle", and others have expressed distaste as well. In draft-kreeger-nvo3-hypervisor-nve-cp-01 we replaced the term with "Information Mapping Authority" (IMA). We would like to get consensus on using this new term in all WG documents going forward. In the meeting Linda expressed a concern that IMA might get confused with IMA being confused with the acronym for Inverse Multiplexing for ATM, and suggested something like "Directory Service" to which David Black replied that she might have trouble convincing people that BGP can be categorized as a "Directory Service". 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. Looking forward to your feedback, Larry _______________________________________________ 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
