Dhruv Dhody <[email protected]> writes: > (2) Sec 3.3 > "The first component consists of a back-end "oracle" that > is responsible for distributing and maintaining the mapping > information for the entire overlay system."
> Should we use the word "oracle" in the ID? IMHO using a more generic term > would be much better. I don't particularly like the term "oracle" myself, but that was the best I was able to come up with. Other suggestions welcome. Note: the whole point of using a term like "oracle" is that it says nothing about how the oracle itself is implemented. As others have mentioned, other terms (like "directory based") have "bagggage" associated with them that could be read to imply particular solution approach. The oracle itself could be implemented as a directory or database of some sort (single instance, distributed, or whatever). Or it could be implemented via an existing (or modified) routing protocol (BGP, IS-IS, etc.). Or it could be implemented as part of the orchestration systems used to manage/migrate VMs. Because there are a range of plausible approaches for implementing the oracle, it seems desirable to use a standardized protocol for the NVE-oracle interaction. The NVE can then use a single protocol to query the oracle for the mappings it doesn't have, or to push mappings to the oracle for any VM's the NVE supports without caring how the oracle itself is implemented/architected. If we have a separate protocol, we aren't tying the NVE to a particular implementation/approach for the oracle. Thomas _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
