First of all, I do not understand why you keep refering to VPN work. This is not what we are discussing here.
Second of all, IRB is a useful feature that is applicable to NVO3 AND it has been specifically mentioned in the dataplane requirements draft. But IRB does not call for a new service type. Third of all, there is no need to repeat over and over again the same sentences. We all know what bridging, routing, and IRB is. It is a waste of time and bandwidth. End of this email thread on my side. Let's hear what others have to say about it. -Marc > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Friday, December 14, 2012 4:29 PM > To: LASSERRE, MARC (MARC); Yves Hertoghs (yhertogh); > [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 > > 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
