Hi Aldrin.
> I think the problem is a matter of perspective/experience. If the
> perspective of NVO3 is through the lens of VLAN/VXLAN/NVGRE/VNET/OTV
> where the VNID has global/network/domain-wide scope and is used
> as-is on the wire, then your questions are quite reasonable as they
> are based on the limitations of these solutions. However if the
> perspective is through the lens of IPVPN and E-VPN then the
> restrictions of one VN-per-VNI and one VNI-per-VN-per-NVE are not
> reasonable since IPVPN/EVPN inherently have support for multiple
> VN-per-VNI and multiple VNI-per-VN-per-NVE.
Let me respin the above a bit differently. If you approach the problem
(as I did) from a DC centric view, where the basic connectivity model
is all nodes on a specific VN have connectivity to other nodes on the
VN, then the idea of some VNs not being able to communicate with other
VNs (by policy) doesn't seem like a particularly important feature to
have. Or, if useful, whether that can just be done outside of NVO3 or
whether it needs to be part of the NVO3 framework.
If you approach the problem from a more traditional VPN perspective
(e.g., BGP VPNs), and one that is heavily influenced by the notion
that VPNS are operating over point-to-point WAN links, existing VPN
solutions have a lot of features/functionality that was developed
(presumably) in response to requirements from that environment.
What I think may be happening here is an assumption that some (or all)
of those existing BGP VPN features apply and/or are also required in a
DC environment. I don't think we should do that. For each feature, we
need to make the case that is useful and a requirement for NVO3, not
just assume that NVO3 inherits all requirements from existing VPN
solutions. We should not assume that DC based overlays have the same
requirements as WAN-oriented VPN solutions.
> > First, you discuss multiple VNIs on the same NVE connected to the
> > same VN. I did not see this illustrated in your diagram, so I
> > didn't have questions about it. From your description, you seem to
> > be making an assumption that there is some kind of firewall policy
> > associated with the VNI. I don't see the benefit of applying
> > firewall policies to VNIs. It seems more straight forward to apply
> > them to the VAPs.
>
> This is indeed in my illustration. I'm resending it. If you look
> at NVE1 and NVE2 you will see that the 2 L2VNI on each of these NVE
> share a "DC<n> mesh" L2VN. The illustration depicts both multiple
> VN per VNI as well as multiple VNI on a single NVE being members of
> the same VN.
I'm having a problem understanding the terminology being used here.
>From the framework doc:
VN: Virtual Network. This is a virtual L2 or L3 domain that belongs
a tenant.
VNI: Virtual Network Instance. This is one instance of a virtual
overlay network. Two Virtual Networks are isolated from one another
and may use overlapping addresses.
A VNI is one specific VN instance.
I do not understand how one can have multiple VNIs associated with a
single VN, it sort of contradicts the defintion of a VNI.
What do you mean when you use the term VNI?
> Regarding features such as filtering implemented at the forwarding
> table (such as VACL) -- L2 ACL on standard dot1q switches are
> usually implemented with VACL not per-port ACL. But to be clear,
> VACL is only one possible example of a feature that can be
> implemented at the forwarding table. Another thing that might be
> implemented at the forwarding table level might be features like
> PVLAN (although I prefer that pvlan solution be implemented using
> overlapping VN model as shown in my illustration).
Without having a discussion about requirements, we should not (IMO)
assume that an NVE needs to provide the equivalent of VACLs. Or if it
does, how that directly impacts the NVO3 framework. ACLs can (of
course) be implemented on an NVE. Whether that (or many other
features) needs to be visible to and a part of the NVE framework is
unclear to me. It might be, but the case needs to be made first.
Thomas
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
