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. > 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. > 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
