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
