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
