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
