I agree with Benson that both modes on tNVE are useful. Hypervispor needs to convey tNVE mode to nNVE. Regardless of the mode, group ID should represent TS's VAP and VDP allows multiple TSes to share the same VAP ID, which covers both modes.
Lucy From: nvo3 [mailto:[email protected]] On Behalf Of Anoop Ghanwani Sent: Sunday, March 22, 2015 9:00 AM To: Benson Schliesser Cc: [email protected]; [email protected] Subject: Re: [nvo3] VDP GroupID vs. VNID in draft-ietf-nvo3-hpvr2nve-cp-req-02 >>> The question is whether the tag represents a link to a specific TS or to a group of TSs. In other words, is the .1Q tag being used to extend the VAP or the VNI between the tNVE and nNVE? >>> To me, I see the tag as extending the VNI (for L2 case only). There are other ways to extend the VAP if that is what is desired an if the source MAC address is not sufficient to achieve that (e.g. S-tags via multichannel or 802.1BR, port extenders). (If we have multiple devices with the same VLAN for which we need to apply policy at the nNVE, how do we do it if the VLAN is used to determine the VAP?) Anoop On Sat, Mar 21, 2015 at 11:23 PM, Benson Schliesser <[email protected]<mailto:[email protected]>> wrote: I suspect that we might be talking past each other here... Let's ignore the terms VEPA, EVB, etc, because we are really focused on the NVO3 architecture in which a TS attaches through a VAP to a VNI. And let's not use "VLAN" because it's really just the .1Q local identifier that we care about (not the LAN service). In the split-NVE scenario the tNVE resides in the end device e.g. hypervisor, and the nNVE resides in the external network element e.g. TOR. What we need in the protocol described by this draft is a mechanism for extending connectivity between the tNVE and nNVE. That connectivity must support multiple logical links, each of which is identified with a .1Q tag. The question is whether the tag represents a link to a specific TS or to a group of TSs. In other words, is the .1Q tag being used to extend the VAP or the VNI between the tNVE and nNVE? Since the NVE-NVA control plane provides information to the nNVE it seems like we need to do all overlay forwarding there. If there is no advanced policy etc then it would be possible to delegate local TS forwarding to the tNVE. But if we need to filter or otherwise apply policy (and services etc) to the local TS forwarding then we must either define a mechanism for communicating that policy to the tNVE, or use the .1Q tag as a VAP extension and perform local TS forwarding on the nNVE. I see use-cases for both models. Local TS forwarding can be more efficient if delegated to the tNVE (depending on the implementation details). But the trust model, policy, etc may require local traffic to be forwarded by an element that is under the NVA's control. -B On Sunday, March 22, 2015, Anoop Ghanwani <[email protected]<mailto:[email protected]>> wrote: I misunderstood what you were saying. The mode of operation where there is no local tNVE switching is referred to as VEPA (virtual Ethernet port aggregator) in IEEE 802.1Qbg. In that case, if you say that a VLAN represents a VAP, what does a VNID represent? For the L2 case, why does it not correspond to a VLAN ID (or a collection of VLAN IDs in the case where translation may be present)? (But your query was about Group ID and the same Group ID can map to different VLANs on different ports.) Anoop On Sat, Mar 21, 2015 at 10:00 PM, Benson Schliesser <[email protected]<mailto:[email protected]>> wrote: Hi, Anoop. Anoop Ghanwani wrote: Let me try and see if I understand this. Everything I know about VDP was learned by reading the draft. So it's rather possible that I don't understand. :) But let me try to clarify my comments here: Basically what you're asking for is for the Group ID to remain a proxy for the VLAN ID, but not necessarily for the VNID. Yes, that's what I mean. But to be explicit, I'm talking about the VLAN ID that is tagged on the wire between the tNVE and nNVE (using the draft's terminology). In the draft, that tag is used to identify a VN. If there are multiple VMs (on the same hypervisor) attached to the same VN, they may have local switching inside the tNVE. My suggestion is that, for some use-cases, the tag could be used to identify a VAP rather than a VN. Therefore e.g. a specific VM interface would be mapped to a tNVE-nNVE VLAN tag, so that the nNVE would be used for all switching (and filtering etc) of inter-VM traffic even if they're on the same hypervisor. In the case of an L2VPN, VNID=VLAN. But in the case of L3VPN a VNID may actually represent a group of VLANs. This is where I'm not sure if we are saying the same thing... Whether or not the VN is used to carry L2 or L3 traffic is orthogonal. In either case (L2 or L3) we may or may not want local tNVE switching. If not then we want the tNVE-nNVE VLAN tag to represent a VAP rather than VN. Cheers, -Benson If so, I agree with your assessment. Anoop On Sat, Mar 21, 2015 at 5:38 PM, Benson Schliesser <[email protected] <mailto:[email protected]<mailto:[email protected]%20%3cmailto:[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]<mailto:[email protected]> <mailto:[email protected]> https://www.ietf.org/mailman/__listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
