Hi Joe, Thanks for the correction. I agree with you about the tNVE/nNVE split. IMO, we should not really consider the tNVE to be an NVE. It is simply something that knows if want to make use of an external device to perform networking. It can be completely unaware of how (or even if) network virtualization is taking place.
Currently, we have been assuming that there is local switching happening, either in the hypervisor vSwitch, or by the classic bridge (if it exists between the hypervisor and the nNVE). All policy enforcement would happen in the nNVE. The tNVE is extremely lightweight and does not even have a channel to the NVA to get the policy to enforce. So, my question to you Benson is, what is the use case for performing policy enforcement within a VN, as opposed to across VNs? - Larry On 3/23/15 3:10 PM, "Joe Pelissier (jopeliss)" <[email protected]> wrote: >A quick correction: What Larry referred to as 802.1qbh is actually >802.1BR. > >802.1BR was not intended to operate across a classic bridge, but anything >is possible ;-) > >Anyway, I think we are getting confused here with the concept that the >NVE is split. As I stated before, in my (probably naïve) opinon, the >external NVE is the NVE, and there is no tNVE. The tennate system is >simply running VDP for any of the many reasons that it might decide to >run VDP, and the network devices (bridge, VEPA, extended bridge, and/or >NVE) do the right thing. The TS does not need to know what network >devices are actually being used to deliver its packets. > >Barely $0.02 worth.. >Joe > >-----Original Message----- >From: nvo3 [mailto:[email protected]] On Behalf Of Larry Kreeger >(kreeger) >Sent: Monday, March 23, 2015 2:57 PM >To: Benson Schliesser; [email protected]; >[email protected] >Subject: Re: [nvo3] VDP GroupID vs. VNID in >draft-ietf-nvo3-hpvr2nve-cp-req-02 > >Hi Benson, > >Chiming in a bit late, but I believe I understand what you are getting at. > >My first comment is that my interpretation of the NVO3 architecture so >far is that policy is applied when traffic enter/leaves a VN. If you >look at the text I recently added to the architecture, I mention that the >main motivation for L2VN to L2VN or L3VN to L3VN gateways are to enforce >policy. >In other words, TS on the same VN are expected to have full communication >with each other. > >Second, (and I need to say I am NOT an expert on the IEEE VEB/VEPA >standards) >is that what you are asking for is covered by 802.1qbh (what we at Cisco >call VN-Tag). I am unsure if it works across a classic bridge or not. >Also, using a single VLAN tag seems like it would be too limiting to >carry all the VAPs, but I could see perhaps Q-in-Q working for your use >case. > > - Larry > >On 3/21/15 7:38 PM, "Benson Schliesser" <[email protected]> wrote: > >>Speaking as an individual contributor to NVO3: >> >>In reviewing draft-ietf-nvo3-hpvr2nve-cp-req-02, it seems to me that >>there is an assumption that a tNVE will perform local switching of e.g. >>inter-VM packets. Based on this assumption, the recommendation seems to >>be that the VDP GroupID is mapped to the VNID for a given VN. >> >>I don't see anything wrong with that particular mode of operation. But >>I do also think it would be valuable to decouple things a bit further... >>Specifically, I can imagine two modes of operation. One of them is as >>described in the draft, where GroupID == VNID. The other might be >>described as GroupID == VAP. >> >>This latter mode might be useful in cases where the nNVE is responsible >>for filtering of some kind, in cases where there are network services >>that must be processed for inter-TS traffic, etc. In fact it seems to >>me that we may want this latter mode to be the default behavior of a >>split NVE. >> >>It's not clear to me how these different modes might be communicated >>via VDP, and/or via the NVE-NVA control plane, if they need to be >>communicated... I'd be interested to hear feedback from the authors and >>any other WG contributors that have thought about this topic. >> >>Thanks, >>-Benson >> > >_______________________________________________ >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
