Lucy, Indeed. This has been my point in a previous email thread. You were the one asking for a new service type for a service that resembles IRB. I, along with a lot more people, do not think that this is necessary as discussed extensively over the mailing list.
As I mentioned in my previous emails, a tenant can have multiple L2 VNs and L3 VNs. The framework draft allows for this. Marc > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Tuesday, March 05, 2013 5:13 PM > To: LASSERRE, MARC (MARC); Linda Dunbar; Benson Schliesser; > [email protected] > Subject: RE: [nvo3] WG Last Call for draft-ietf-nvo3-framework-02 > > Marc, > > I don't know what the technologies you hint to and assume > that you mean L2VPN and L3VPN specified in IETF. L2VPN is for > intra subnet. L3VPN can apply for both intra and inter > subnet. SP typically offer either L2VPN or L3VPN service to > customer, which is why IETF worked that way. In DC, DC > provider need to offer customer a network that may contain > multiple VNs, where some may be L2 overlay and some L3 > overlay. IRB has been used in the network, but it is not > offered as a service to customer nor in overlay mode. Further > IETF has no specification to it too. Thus, we can't assume > that is a standard technology referring to here. > > Regards, > Lucy > > > -----Original Message----- > > From: LASSERRE, MARC (MARC) > [mailto:[email protected]] > > Sent: Tuesday, March 05, 2013 4:53 AM > > To: Linda Dunbar; Lucy yong; Benson Schliesser; [email protected] > > Subject: RE: [nvo3] WG Last Call for draft-ietf-nvo3-framework-02 > > > > Linda, > > > > I do not see why nvo3 differs from other technologies when > it comes to > > switching and routing. > > > > Obviously a tenant may have different VNs. Communication > within an L2 > > VN is based on traditional switching, Communication across > L2 VNs is > > based on tradtional routing. IRB-like capabilities (as I think that > > this is what you are hinting) can be supported but this is > > implementation specific. > > > > Hence, I'm not sure what a specific "inter-subnet communication" > > section would contain. > > > > Marc > > > > > > > -----Original Message----- > > > From: [email protected] > [mailto:[email protected]] On Behalf > > > Of Linda Dunbar > > > Sent: Monday, March 04, 2013 11:05 PM > > > To: Lucy yong; Benson Schliesser; [email protected] > > > Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-framework-02 > > > > > > I second Lucy's comments. > > > > > > Inter Virtual Network communication (or inter subnet > > > communication) is a big part of data centers. Hosts in > data center > > > do communicate with external peers. Many tenants to DC need more > > > than one Virtual Network Instances. And hosts in those virtual > > > network instances do communicate with each other and some > > > communicate with peers via public internet. > > > > > > > > > IMHO, Inter-subnet communication set NV03 apart from > other overlay > > > done by IETF, such as L2VPN, TRILL, LISP, etc. > > > Therefore, the framework should have a section on "inter Subnet > > > Communication". > > > > > > There are some inter virtual network discussion in > > > > http://datatracker.ietf.org/doc/draft-yong-nvo3-frwk-dpreq-addition/. > > > The content from this draft should be included in the general > > > framework. > > > > > > > > > Linda > > > > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]] > > > On Behalf > > > > Of Lucy yong > > > > Sent: Monday, March 04, 2013 12:22 PM > > > > To: Benson Schliesser; [email protected] > > > > Subject: Re: [nvo3] WG Last Call for > draft-ietf-nvo3-framework-02 > > > > > > > > I read this version and glad to see adding a section for VM > > > mobility. > > > > > > > > Some comments: > > > > > > > > 1) The introduction states that the rationale for using overlay > > > > networks in DC is for building multi-tenant data center > > > networks. It > > > > also mentions that a tenant network may consist of one or > > > more virtual > > > > networks. However, the architecture and reference model is > > > focusing on > > > > single virtual network overlay architecture only. It is lack of > > > > describing the architecture and model about multiple > > > virtual networks > > > > forming one tenant network, i.e. virtual network overlay > > > > interconnections. > > > > > > > > Thus, a question to the WG chair, is this the scope for > nvo3 WG? > > > > If yes, that is fine and the framework document should make it > > > very clear > > > > that the framework document describes architecture model of > > > a virtual > > > > network and only applies to a tenant network if it > consists of one > > > > virtual network that may be implemented by either L2 > overlay or L3 > > > > overlay. a tenant network that contain more than one > > > virtual networks > > > > is outside scope of this document. If not, we can > either have one > > > > framework draft to architect both, or we have two separate > > > documents, > > > > one to intra virtual network overlay and another for > inter virtual > > > > network overlay. > > > > > > > > Without clarifying this, I am not clear if the framework > > > document is > > > > working on a virtual network over L3 infrastructure or a tenant > > > > network over L3 infrastructure. Two are not equivalents. > > > > > > > > 2) Figure 2 illustrate a logical service connectivity > for a single > > > > tenant. First of all, it should not show L3 > infrastructure in the > > > > figure at all. Second, I interpret this figure as one > > > tenant network > > > > consisting of four virtual networks, three L2 virtual > > > networks and one > > > > L3 virtual network. It should point out that VMs on a > L2 virtual > > > > network may reside on the same or different servers. The > > > drawing and > > > > team LAN make easy to thing they are physical LANs. In fact > > > they are > > > > not. VM on LAN11 and VM on LAN12 may reside on the same > > > server. Thus > > > > it is very important to state them out clearly. Finally, > > > based on my > > > > comment 1), it should clarify what this document address > > > regarding to > > > > this figure here. > > > > > > > > 3) in Section 3.3, "In DC environments utilizing VM > > > technologies, an > > > > important feature > > > > is that VMs can move from one server to another > > > server in the > > > > same > > > > or different L2 physical domains (within or > across DCs) in a > > > > seamless manner." > > > > > > > > What does the L2 physical domain mean here? Why need to > > > mention this? > > > > > > > > > > > > Cheers, > > > > Lucy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: [email protected] > > > [mailto:[email protected]] On Behalf > > > > Of > > > > > Benson Schliesser > > > > > Sent: Friday, February 22, 2013 6:28 PM > > > > > To: [email protected] > > > > > Subject: [nvo3] WG Last Call for draft-ietf-nvo3-framework-02 > > > > > > > > > > This email begins a two week working group last call for > > > > > draft-ietf-nvo3-framework-02. > > > > > > > > > > Please review the draft and post any comments to the > NVO3 list. > > > > > > > > > > This working group last call will end on Friday 08-March-2013. > > > > > > > > > > Cheers, > > > > > -Benson & Matthew > > > > > _______________________________________________ > > > > > 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
