Marc, I have to say there is nothing new there, L2 VPN and L3 VPN have been standardized long time ago and deployed widely. Why do we work on this now and standardize them again?
Let me also answer why we work on "here" and "there" now. L2VPN and L3VPN was developed for network service providers who can offer services to customers. The customers typically have either a switch or router to interface with service provider edge device that VPN function enables. IRB function has been used a lot in the enterprise networks, but not in service provider's. L2VPN provides Ethernet LAN like networking, where a customer can use it for the communication on one subnet. L3VPN provides IP routing across WAN network, where a customer can use it for the communication among one or different subnets at different sites, but CE at a site has to use layer 3 interface. A tenant virtual network in DC may contain one or more subnets. It requires bridging mechanism for the communication within one subnet and routing mechanism for the communication among one or different subnets with Ethernet interface only, i.e. CE has be L2 interface. The latter is similar to the IRB function. Current IRB function on router is local function, so there is no need to be standardized. However, in a tenant virtual network, TSes on the same subnet can be on a same or different NVEs and/or moves to different NVEs, so it is no longer a local function. IMO: this is the reason why we need to define a new service type for this. Regards, Lucy > -----Original Message----- > From: LASSERRE, MARC (MARC) [mailto:[email protected]] > Sent: Friday, December 14, 2012 4:14 AM > To: Lucy yong; Yves Hertoghs (yhertogh); [email protected]; > [email protected]; Bocci, Matthew (Matthew) > Cc: [email protected]; draft-bl-nvo3-dataplane- > [email protected] > Subject: RE: [nvo3] FW: New Version Notification for draft-yong-nvo3- > frwk-dpreq-addition-00.txt > > Lucy, > > There is nothing new here. It is standard bridging and routing. > Hence IRB does not call for a new service type. > > Marc > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Lucy yong > > Sent: Thursday, December 13, 2012 11:29 PM > > To: Yves Hertoghs (yhertogh); LASSERRE, MARC (MARC); > > [email protected]; [email protected]; Bocci, Matthew (Matthew) > > Cc: [email protected]; > > [email protected] > > Subject: Re: [nvo3] FW: New Version Notification for > > draft-yong-nvo3-frwk-dpreq-addition-00.txt > > > > Yves, > > > > As the draft describes, TS uses ARP to discover the > > destination MAC that are on the same subnet and send Ethernet > > frame to other TS on the same subnet directly. TS sends the > > Ethernet frame to the gateway if the destination of the > > packets are on different subnet. L2-3 NVE acts as the gateway > > for a Tenant virtual network. When it gets the packets, it > > performs an IP look-up and find the corresponding MAC > > address, and replace the gateway MAC address with the MAC > > address before sending it out. TS uses ARP to find out the > > gateway MAC address and cache it. I call this as MAC address > > translation in data plane. > > > > Hope this is clear. > > > > Lucy > > > > > -----Original Message----- > > > From: Yves Hertoghs (yhertogh) [mailto:[email protected]] > > > Sent: Thursday, December 13, 2012 3:52 PM > > > To: Lucy yong; LASSERRE, MARC (MARC); [email protected]; > > > [email protected]; Bocci, Matthew (Matthew) > > > Cc: [email protected]; > > draft-bl-nvo3-dataplane- > > > [email protected] > > > Subject: RE: [nvo3] FW: New Version Notification for > > draft-yong-nvo3- > > > frwk-dpreq-addition-00.txt > > > > > > Lucy, > > > > > > Why would IRB require MAC Address translation. IRB is nothing else > > > than sticking an internal routed interface on top of a > > bridge domain, > > > with > > > L2 interfaces sticking out of the node. Packets destined > > to the mac- > > > address associated with the routed interface get routed (and would > > > show up at the network side with a new mac-header), other > > ones get bridged. > > > > > > Yves > > > > > > > > > > > > > -----Original Message----- > > > > From: [email protected] > > [mailto:[email protected]] On Behalf > > > Of > > > > Lucy yong > > > > Sent: Thursday, December 13, 2012 18:16 > > > > To: LASSERRE, MARC (MARC); [email protected]; [email protected]; > > > Bocci, > > > > Matthew (Matthew) > > > > Cc: [email protected]; draft-bl-nvo3- > > > dataplane- > > > > [email protected] > > > > Subject: Re: [nvo3] FW: New Version Notification for > > > > draft-yong-nvo3- > > > frwk- > > > > dpreq-addition-00.txt > > > > > > > > Marc, > > > > > > > > NVO3 work is not just to repeat what we have done before. I am > not > > > aware > > > > of a specific RFC describes IRB. But as you pointed out, IRB is > > > widely deployed > > > > in the physical networks today, but it is not in VPN bases. > Please > > > look at > > > > Microsoft hyper-v, it also implements IRB for network > > virtualization. > > > > > > > > I know that the combination of L2 NVE and L3 NVE can serve some > > > > applications and it is useful, but it is not equivalent to IRB > > > function. To > > > > support IRB function, the data plane has to perform MAC address > > > translation > > > > and prevent the broadcast traffic in one subnet network > > from sending > > > to > > > > another. There is no such requirement in current data plane > > > requirement > > > > document. > > > > > > > > Hope this convince you a new service type of NVE. > > > > > > > > Regards, > > > > Lucy > > > > > > > > > -----Original Message----- > > > > > From: LASSERRE, MARC (MARC) [mailto:marc.lasserre@alcatel- > > > lucent.com] > > > > > Sent: Thursday, December 13, 2012 4:17 AM > > > > > To: Lucy yong; [email protected]; [email protected]; Bocci, > > > > > Matthew > > > > > (Matthew) > > > > > Cc: [email protected]; draft-bl-nvo3- > > > dataplane- > > > > > [email protected] > > > > > Subject: RE: [nvo3] FW: New Version Notification for draft- > yong- > > > nvo3- > > > > > frwk-dpreq-addition-00.txt > > > > > > > > > > Lucy, > > > > > > > > > > The statement "Neither of them naturally supports the > > > > > communication among the VMs When some VMs are on the > > same subnet > > > > > and other on different" in the introduction of your > > draft is inaccurate. > > > > > > > > > > Integrated routing and switching is > > configuration/implementation > > > > > specific to a router. > > > > > Can you point to a specific RFC that describes IRB and a new > > > interface > > > > > type? > > > > > This capibility can be enabled as already mentioned in the > > > dataplane > > > > > requirements draft. > > > > > Hence, there is no need to specify a new NVE service type. > > > > > > > > > > As far as mobility is concerned, I'm finishing up a new section > > > > > for the framework draft. > > > > > > > > > > Marc > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: [email protected] [mailto:[email protected]] On > > > Behalf > > > > > > Of Lucy yong > > > > > > Sent: Tuesday, December 11, 2012 11:19 PM > > > > > > To: [email protected]; [email protected]; Bocci, Matthew > > > > > > (Matthew) > > > > > > Cc: [email protected]; > > > > > > [email protected] > > > > > > Subject: [nvo3] FW: New Version Notification for > > > > > > draft-yong-nvo3-frwk-dpreq-addition-00.txt > > > > > > > > > > > > Hello, > > > > > > > > > > > > FYI. We just upload this draft. It provides additions to the > > > > > > nvo3 framework and data plane requirement beside current > > > documents. > > > > > > The objective of this draft is to merge the suggested > > text into > > > the > > > > > > framework and data plane requirement documents. > > > > > > > > > > > > Your comments on this are welcome. > > > > > > > > > > > > Regards, > > > > > > Lucy > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: [email protected] > > > > > > > [mailto:[email protected]] > > > > > > > Sent: Tuesday, December 11, 2012 4:04 PM > > > > > > > To: Lucy yong > > > > > > > Cc: Linda Dunbar > > > > > > > Subject: New Version Notification for draft-yong-nvo3-frwk- > > > dpreq- > > > > > > > addition-00.txt > > > > > > > > > > > > > > > > > > > > > A new version of I-D, draft-yong-nvo3-frwk-dpreq-addition- > > > 00.txt > > > > > > > has been successfully submitted by Lucy Yong and > > posted to the > > > > > > > IETF repository. > > > > > > > > > > > > > > Filename: draft-yong-nvo3-frwk-dpreq-addition > > > > > > > Revision: 00 > > > > > > > Title: NVO3 Framework and Data Plane > > > > > > Requirement Addition > > > > > > > Creation date: 2012-12-11 > > > > > > > WG ID: Individual Submission > > > > > > > Number of pages: 9 > > > > > > > URL: > > > > > > http://www.ietf.org/internet-drafts/draft-yong-nvo3- > > > > > > > frwk-dpreq-addition-00.txt > > > > > > > Status: > > > > > > http://datatracker.ietf.org/doc/draft-yong-nvo3-frwk- > > > > > > > dpreq-addition > > > > > > > Htmlized: > > > > > > http://tools.ietf.org/html/draft-yong-nvo3-frwk-dpreq- > > > > > > > addition-00 > > > > > > > > > > > > > > > > > > > > > Abstract: > > > > > > > This document describes some additional functions and > > > > > > requirements > > > > > > > for NVO3 framework [NVO3FRWK] and data plane > > > > > > requirements [DPREQ]. > > > > > > > These additions are necessary in supporting VM > > > > > > > communication > > > and > > > > > > > mobility. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > > > _______________________________________________ > > > > > > 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
