Larry, What you said works, but it requires VLAN configuration on the NVE.
If NVE and NVA are in trusted domain, you can also let NVE to announce both NVE and NVA's IP Addresses or even let NVA use the same IP address as NVE, especially when a NVE has the built in mapping database (e.g. the NVE that is co-located with GW). That is what I am referring to as NVE proxy for NVA. This is especially true when a GW has gets the mappings for all hosts in the DC either by a scrip file (as done by Microsoft system center), or by other off-net methods. Anyway, I think those points that describe various relationship between NVE&NVA should be captured in the NVE<->NVA requirement. Linda > -----Original Message----- > > LK> I don't see why either of the above needs to be true. If the ToR > can > provide traditional 802.1Q VLANs in addition to the NVE function, the > NVA > simply needs be connected to a port on the ToR which is on a VLAN that > eventually leads to the router providing connected to the IP underlay. > There is no reason for the ToR to proxy for the NVA or route. It > should > be no different from two separate ToRs, one To R that is only 802.1Q > capable which one VLAN connected to an underlay router, another ToR > that > only provides NVE functionality. Implementors can put both functions > inside the same ToR (I would recommend it). > > > > > > > > >> All this is avoided by having the NVA connect to the underlay and be > >> accessible via underlay addresses. > > > >[Linda] My above comment should address this issue. > > > >Linda > > > >_______________________________________________ > >nvo3 mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
