HI Lucy: Your point completely escapes me. Could you clarify?
Cheers Dave -----Original Message----- From: Lucy yong [mailto:[email protected]] Sent: Tuesday, November 26, 2013 6:51 AM To: David Allan I; Black, David Cc: [email protected] Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service David, Please see inline. -----Original Message----- From: David Allan I [mailto:[email protected]] Sent: Monday, November 25, 2013 6:30 PM To: Lucy yong; Black, David Cc: [email protected] Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, Any non-interconnect of tenant networks in a common routing implementation will require lots of ACLs which can be gotten wrong, and would not permit reuse of private addressing by multiple tenants sharing a router FDB....and could be messed up by duplicate MAC addresses. [Lucy] agreed. SHOULD not use ACL doing that. IMO it is a bad idea, it places a lot of constraints on virtualization (e.g. it can only work if..and if... and if...etc.) so it becomes somewhat half baked. If a tenant requires multiple interconnected subnets they need their own VRF/VR implementation, own ARP cache etc to obviate the potential problems. Why would we WANT to allow otherwise? [Lucy] Agreed. But NVO3 goal is the solution in multi-tenancy environment. Network virtualization needs to figure out an efficient and secure way to implement it. Software can do a lot. :) Thanks, Lucy My 2 cents Dave -----Original Message----- From: nvo3 [mailto:[email protected]] On Behalf Of Lucy yong Sent: Monday, November 25, 2013 8:12 AM To: Black, David Cc: [email protected] Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi David, Please see inline. -----Original Message----- From: Black, David [mailto:[email protected]] Sent: Monday, November 25, 2013 8:36 AM To: Lucy yong Cc: [email protected] Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, > Here is my 2cent whether combined L2/L3 service is architecturally > same or different from the non-overlay IRB case used today. > > They are the same in term of the function feature, i.e. a router can > provide bridging capability for intra VLAN traffic, and bridging > capability for inter VLANs traffic via routing. > > But they have differences too. First, an NVE supports this feature in > term of multi-tenancy environment, while a route does it in a single > tenancy case (in one address space only). I firmly disagree. VLANs can be used for multi-tenancy, with the result that there can be multiple instances of the router function in the same physical network node in multiple IP address spaces. [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context, we talk about a router device with bridge capability (i.e. IRB), Isn't such device operated under one L3 address space, including physical network address space and source/destination address space? In other words, endpoint and physical network are on the same address space. In traditional DC environment, even VLAN can provide virtual networks, MAC address is uniquely assigned to physical device, so it is effectively only one MAC address space regardless whether VLAN is used or not. VLAN provides a virtual private network, it was not originally intended to provide independent address spaces. > Second, an NVE has both VAP interfaces and overlay tunnel interfaces > plus internal gw interface. A router only has ports or L2 interfaces, > which are equivalent to the VAPs on NVE case. (you point out this) I think this is over-simplified. A router has interfaces that correspond to both overlay tunnel interfaces and its internal gateway (not sure whether this was intended to be the gateway facing end systems, or the interface that "default" is pointed at, if applicable, but the analogy holds for both). For a non-overlay environment, these interfaces are not encapsulated, but in general, a router has L2/link connectivity to other routers, not just end systems. [Lucy] I may over-simplify the router to focus on this case only. My point is that the router device in this case typically handles one L3 address space and one MAC address space in the reality. Lucy > In a multi-tenancy environment, an NVE may be the member for multiple VNs. And a physical routing implementation may provide logically distinct routing for multiple VLANs. > Some VN may have independent address spaces, some may share the same > address space. An NVE needs to have a VN interconnection policy table > which indicates which VNs can communicate and which VNs can't Likewise for routing and VLANs. > Furthermore the policy may have > finer granularity to a level. For example, between L2VNx and L2VNy, > the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > IMO: the inter-VN policy should be controlled at the VN level, not to > the particular address (ACL level) or particular application (TCP, > HTTP level) in the VNs. The latter belongs to the firewall function. And also likewise for routing and VLANs. Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Sunday, November 24, 2013 7:50 PM > To: Black, David; Erik Nordmark > Cc: [email protected] > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > Service > > Here is my 2cent whether combined L2/L3 service is architecturally > same or different from the non-overlay IRB case used today. > > They are the same in term of the function feature, i.e. a router can > provide bridging capability for intra VLAN traffic, and bridging > capability for inter VLANs traffic via routing. > > But they have differences too. First, an NVE supports this feature in > term of multi-tenancy environment, while a route does it in a single > tenancy case (in one address space only). Second, an NVE has both VAP > interfaces and overlay tunnel interfaces plus internal gw interface. > A router only has ports or L2 interfaces, which are equivalent to the > VAPs on NVE case. (you point out this) > > In a multi-tenancy environment, an NVE may be the member for multiple VNs. > Some VN may have independent address spaces, some may share the same > address space. An NVE needs to have a VN interconnection policy table > which indicates which VNs can communicate and which VNs can't. > Furthermore the policy may have finer granularity to a level. For > example, between L2VNx and L2VNy, the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > IMO: the inter-VN policy should be controlled at the VN level, not to > the particular address (ACL level) or particular application (TCP, > HTTP level) in the VNs. The latter belongs to the firewall function. > > Lucy > > > > > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Black, David > Sent: Friday, November 22, 2013 6:40 PM > To: Erik Nordmark > Cc: [email protected] > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > Service > > Writing as an individual, not co-author of draft-narten-nvo3-arch: > > > What is missing for me is a higher-level statement whether or not we > > see an NVE providing combined L2 and L3 service as being > > architecturally different that the non-overlay case of a > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we > > need more details that Thomas' text above. > > IMHO, it should be architecturally the same, and we should say so. > The quoted text was intended to head in that direction, so an explicit > statement > seems like a fine idea. I think the touchstone for how L3 service is > provided > in an L2/L3 service combination should be: "what would happen if there > was no network virtualization?" > > Thanks, > --David > > > -----Original Message----- > > From: nvo3 [mailto:[email protected]] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong; > > Thomas Narten > > Cc: [email protected]; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > > Service > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on the inner > > > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how > > switches/routers process packets i.e. based on frame's destination > > MAC and destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite > > > well and > > concisely. > > > > > >>> <t> > > >>> A virtual network can also provide a combined L2 and L3 > > >>> service to tenants. In such cases, a tenant sends and > > >>> receives both L2 and L3 packets. An NVE recieving packets > > >>> from a TS determines the type of service to be applied to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as provided by the TS. If > > >>> the MAC address corresponds to that of an L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service presents no special > > >>> considerations for NVO3, other than packets received from a > > >>> tenant must be classified as to what type of service they > > >>> are to be given before they can be processed. > > >>> </t> > > > > What is missing for me is a higher-level statement whether or not we > > see an NVE providing combined L2 and L3 service as being > > architecturally different that the non-overlay case of a > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we > > need more details that Thomas' text above. > > > > FWIW the existing bridge+routers handle multicast conceptually as > > bridge-route-bridge. A received multicast packet might need to be > > bridged out other L2 ports in the same bridge domain. Then one copy > > of packet is passed to the L3 function, which does L3 multicast > > routing (check iIF, decrement ttl, determine oIFs). Finally, a given > > L3 oIF might correspond to a bridge domain i.e., multiple packets > > might need to be sent out different L2 ports for each oIF. > > > > While that is a bit complex, it is a lot better if the NVO3 > > architecture is the same as existing combined bridge+router boxes. > > > > And note that an existing combined bridge+router is architecturally > > consistent with separate bridges and a router where the bridges only > > do > > L2 and the router only does L3. > > > > Erik > > > > > > _______________________________________________ > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
