Hi Benson, Yes, the term "End Device" is consistent with draft-ietf-nvo3-hpvr2nve-cp-req-00 <https://datatracker.ietf.org/doc/draft-ietf-nvo3-hpvr2nve-cp-req/>, and the NVO3 Framework document.
Thanks, Larry On 8/26/14 6:46 PM, "Benson Schliesser" <[email protected]> wrote: >Hi, Larry. > >On Aug 25, 2014, at 9:22 PM, Larry Kreeger (kreeger) <[email protected]> >wrote: > >> Overall, I think this is much better. I have a few nits inline below. > >Thanks for the constructive feedback. Comments inline. > >>> An NVO3 solution is a set of protocols and/or protocol extensions that >>> enable >>> network virtualization within a data center (DC) environment using an >>> IP-based >>> overlay approach. It provides layer 2 and layer 3 services >> >> LK> I would say "layer 2 and/or layer 3", saying only and implies both >> services are always present in an NVO3 solution. > >Agreed. > >>> The NVO3 WG may produce requirements for a network virtualization >>>control >>> plane, and will select, extend, and/or develop one or more control >>>plane >>> protocols to support the architecture. Such protocols are expected to >>> fulfill >>> the communication requirements between a Tenant System (TS) and Network >>> Virtualization Edge (NVE), >> >> LK> I think when you say TS above, you really mean the Hypervisor or an >> End Device such as a Network Service Appliance where the NVE is split >>with >> the encap/decap happening in another device, such as a TOR switch. We >> have been steering clear of having the untrusted Tenant Systems >>signaling >> what networks they want to connect to. > >Your interpretation is correct, and I can see that my text is not right. >If I change TS to "End Device² does that make it correct? Or do you have >a different suggestion for the text? > >Thanks, >-Benson > > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
