David, I know that NVO3 architecture targets multi-tenant environment from day one.
Eric initially question is if combined L3/L2 service in NVO3 is the architecturally same as the today's router with bridging capability, i.e. IRB used in a physical network today. This is the router I referenced in my mail. I think that my view is the same as yours. Thanks, Lucy -----Original Message----- From: Black, David [mailto:[email protected]] Sent: Monday, November 25, 2013 11:56 AM To: Lucy yong Cc: [email protected] Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, > > 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. -- > 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? No, we aren't talking about a single "router device" - when I wrote "multiple instances of the router function", I meant a device that can operate multiple instances of the router function that can be in separate source/destination address spaces (e.g., I expect to see multiple independent instances of the 10.0.0.0/8 address block in a multi-tenant data center). In addition, an NVE has to deal with the underlay address space. I view that underlay address space as secondary - the routing function makes an IP routing decision about where to forward a packet. That decision is about what "logical port" to emit the packet on ("logical interface" is a better term in this context) - the encapsulation and the underlay address are functional consequences of that forwarding decision. > [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. See above on "multiple instances" of the "router". Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Monday, November 25, 2013 11: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
