David, > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, July 03, 2012 2:48 PM > To: Luyuan Fang (lufang); [email protected]; Benson Schliesser (bschlies) > Cc: [email protected] > Subject: VPN4DC draft scope > > Luyuan > > > > Again, this is not what our draft is about, namely it is not about > > > tenants wanting to "extend" their L3VPN to SP or cloud provider > data > > > centers. > > While that may have been the intention, Section 12 ("IP-VPN Data Center > Use Case: Virtualization of Mobile Network") is not about data centers; > it's about mobile networks. > > Can I suggest replacing that section with an actual Data Center use > case > that doesn't extend beyond the data center?
[lf] It is for Mobility DC virtualization. It was raised from multiple real cases we were asked to address. Agree, things not about DC are out of scope. We can re-work the text to be clear it is all about Mobility DC. Mobile infra is not the focus, but it is the environment the mobile DCs living in, can be brief. Some text in this subsection is clear about dc, such as the text below. Other may need rewording and revising. It is a good point. ... Using the same VPN technology in the service provider Data Center network (or in a public Data Center network) is a natural extension. > > > > problem statement > > > for layer 3 VPNs as a data center virtualization solution, and then > we > > > extended it with the requirements for such a solution. > > Let's be precise - a specific solution has been chosen, namely BGP/MPLS > L3VPNs, as indicated in the first sentence of the abstract as well as > the > entirety of Section 10 and its subsections. > > I agree that this could be a problem statement and requirements draft, > but > it needs an accurate title, e.g.: > > BGP/MPLS VPN Data Center Problem Statement and Requirements > > IMHO, IP-VPN is too broad, as the draft is considerably narrower than > would > be required to cover all IP VPNs (e.g., IPsec VPNs as Linda mentioned). > > I'm not suggesting that IPsec VPNs are a good nvo3 solution for data > centers > (they may play a complementary role in some cases), rather I'm using > IPsec > VPNs as an example to ask that the draft have a title that reflects its > actual content. [lf] Agree with your comments on making it explicit in the title, we will do so and will clarify on the terms we use in this doc as well in the next revision. If you followed the Taiwan meeting and all the activities going on in Routing area around DC, this is the continued work for vpn4dc. In the last IETF in Paris, it was said that nvo3 would expand its original scope to include vpn, so we brought the work here. We do not pretend to be something else. We do not claim to cover all issues in nvo3, and we do not believe other drafts covered them all either. Anything we need to clarify/improve, not an issue. We welcome all comments to shape it up. > > Thanks, > --David > Thanks, Luyuan > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > Of Luyuan > > Fang (lufang) > > Sent: Tuesday, July 03, 2012 12:58 PM > > To: NAPIERALA, MARIA H; Linda Dunbar; Yakov Rekhter; Benson > Schliesser > > (bschlies) > > Cc: Pedro Marques; Matthew (Matthew) Bocci; draft-narten-nvo3- > overlay-problem- > > [email protected]; [email protected]; Dennis Cai (dcai) > > Subject: Re: [nvo3] call for adoption: draft-narten-nvo3-overlay- > problem- > > statement-02 > > > > Linda, > > > > See-line. > > > > > -----Original Message----- > > > From: NAPIERALA, MARIA H [mailto:[email protected]] > > > Sent: Monday, July 02, 2012 3:22 PM > > > To: Linda Dunbar; Yakov Rekhter; Benson Schliesser (bschlies) > > > Cc: Matthew (Matthew) Bocci; Luyuan Fang (lufang); [email protected]; > > > Dennis Cai (dcai); Pedro Marques; draft-narten-nvo3-overlay- > problem- > > > [email protected] > > > Subject: RE: [nvo3] call for adoption: draft-narten-nvo3-overlay- > > > problem-statement-02 > > > > > > Linda, > > > > > > Thanks for the comments. > > > > > > > > > > > Your draft (http://www.ietf.org/id/draft-fang-vpn4dc-problem- > > > statement- > > > > 01.txt ) demonstrates the approaches on how to extend L3VPN to > end > > > > systems in data center. "draft-narten-nvo3-problem-statement" > > > > describes the issues facing data centers with massive number of > VMs > > > > interconnected by virtualized switches. > > > > [lf] Good point to bring up - "massive number of VMs...", scaling is > one of > > our key motivation to focus on l3 for its proven scalability. > > > > > > > > > > Majority of text in your draft is on how L3VPN can be extended to > > > Data > > > > Center. It would be good solution draft, > > > > [lf] No. Can people implement equipments with this draft and have > inter- > > operability? if not, then it is not solution draft. > > It is pb statement and req. as titled. > > > > > > because some tenants do want > > > > to extend their VPNs (L2 or L3) into data centers. > > > > > > Our draft is not about "extending" tenant's L3VPNs to data centers > but > > > using L3VPNs as a data center virtualized solution. Is a combined > > > problem statement/requirements draft for a data center > virtualization > > > using L3VPNs, including large scale data centers with massive > number of > > > VMs. It is not a solution draft. The solution draft is draft- > marques- > > > l3vpn-end-system, for example. > > > > > [lf] We are addressing both intra-DC and inter-DC, it is about DC > > virtualization as Maria pointed out. > > > > > > If you want to merge your draft to general NVo3 problem > statement, a > > > > lot of sections in your draft need to be removed. For example, > > > Section > > > > 7 on how MAC addresses should not be used, etc. MAC addresses > don't > > > > have to be used in the solution described in your draft. > > > > [lf] The authors have not discussed merge yet. We are open to > discussion. But > > as discussed by Joel and Rob too, how practical to express very > different > > problems, requirements, and framework in one doc is a good question. > > > > > > But not all > > > > data centers will use L3VPN. > > [lf] Correct, but it is true for any technologies regardless dc or > not. > > > > > > Many data centers don't have any end > > > > systems which are part of any L3VPN; > > [lf] that is why the pb statement and requirement effort. > > > > > > Many data centers only allow > > > IPSec > > > > tunnels terminated at their gateways; Some multi-tenant data > centers > > > > have to use L2 among VMs due to their tenant's requirement. > > > > [lf] We don't go against l2, it is needed and there are plenty people > working > > on it. But nothing prevent developing l3. A few modern large scale > DCs already > > deployed all l3 solutions with their own implementation. Providers > are anxious > > to get standardized l3 solutions. So we start with pb and req. > > > > > > Since NVo3 current charter is only on studying problems and > identify > > > > requirement, > > [lf] that is exactly what we have. Could you point out where in the > charter > > indicate we are out if you are still not convinced? > > > > > > it might be worthwhile to revise your draft focusing > > > > only > > > > on the problems facing data centers when some tenants need to > extend > > > > their L3VPN to VMs within data centers. > > > > > > Again, this is not what our draft is about, namely it is not about > > > tenants wanting to "extend" their L3VPN to SP or cloud provider > data > > > centers. > > > > > > As Luyuan explained before, the draft has started a problem > statement > > > for layer 3 VPNs as a data center virtualization solution, and then > we > > > extended it with the requirements for such a solution. > > > > > > > > > Thanks! > > > Maria > > > > > Thanks, > > Luyuan > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]] On > > > Behalf > > > > Of > > > > > Yakov Rekhter > > > > > Sent: Thursday, June 21, 2012 2:44 AM > > > > > To: Benson Schliesser > > > > > Cc: Matthew (Matthew) Bocci; Luyuan Fang (lufang); > [email protected]; > > > > > Dennis Cai (dcai); Pedro Marques; draft-narten-nvo3-overlay- > > > problem- > > > > > [email protected]; [email protected] > > > > > Subject: Re: [nvo3] call for adoption: draft-narten-nvo3- > overlay- > > > > > problem-statement-02 > > > > > > > > > > Benson, > > > > > > > > > > > Dear NVO3 Participants - > > > > > > > > > > > > This message begins a two week Call for Adoption of > > > > > > http://tools.ietf.org/html/draft-narten-nvo3-overlay-problem- > > > > > statement-02 > > > > > > by the NVO3 working group, ending on 30-June-2012. > > > > > > > > > > > > Please respond to the NVO3 mailing list with any statements > of > > > > > approval > > > > > > or disapproval, along with any additional comments that might > > > > explain > > > > > > your position. Also, if any NVO3 participant is aware of IPR > > > > > associated > > > > > > with this draft, please inform the mailing list and/or the > NVO3 > > > > > chairs. > > > > > > > > > > Before considering adoption of draft-narten-nvo3-overlay- > problem- > > > > > statement, > > > > > we should consider how this draft is related to > > > > > draft-fang-vpn4dc-problem-statement (see below) ? Do these two > > > drafts > > > > > cover the same topic ? Are they complementary with each other ? > > > > > Should both of these drafts be merged into a single draft, > before > > > > > being adopted by the NVO3 working group ? > > > > > > > > > > Yakov. > > > > > > > > > > --------------------------------------------------------------- > ---- > > > -- > > > > -- > > > > > Date: Wed, 20 Jun 2012 10:50:53 CDT > > > > > To: <[email protected]> > > > > > cc: Pedro Marques <[email protected]>, > > > > [email protected], > > > > > "Dennis Cai \(dcai\)" <[email protected]> > > > > > From: "Luyuan Fang (lufang)" <[email protected]> > > > > > Subject: [nvo3] FW: New Version Notification fordraft-fang- > vpn4dc- > > > > > problem-sta > > > > > ***tement-01.txt > > > > > > > > > > Dear colleagues, > > > > > > > > > > We have uploaded a new updated version of draft-fang-vpn4dc- > > > problem- > > > > > statement > > > > > -01.txt (on 6/12), by Maria Napierala, Dennis Cai, and myself. > > > > > Appreciate your review and comments. > > > > > > > > > > Thanks, > > > > > Luyuan > > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:internet- > [email protected]] > > > > > Sent: Tuesday, June 12, 2012 10:48 PM > > > > > To: Luyuan Fang (lufang) > > > > > Cc: [email protected]; Dennis Cai (dcai) > > > > > Subject: New Version Notification fordraft-fang-vpn4dc-problem- > > > > > statement-01.t > > > > > xt > > > > > > > > > > > > > > > A new version of I-D, draft-fang-vpn4dc-problem-statement- > 01.txt > > > > > has been successfully submitted by Luyuan Fang and posted to > the > > > > > IETF repository. > > > > > > > > > > Filename: draft-fang-vpn4dc-problem-statement > > > > > Revision: 01 > > > > > Title: IP-VPN Data Center Problem Statement and > > > > > Requirements > > > > > Creation date: 2012-06-12 > > > > > WG ID: Individual Submission > > > > > Number of pages: 18 > > > > > URL: http://www.ietf.org/internet-drafts/draft- > fang- > > > > vpn4dc- > > > > > proble > > > > > m-statement-01.txt > > > > > Status: http://datatracker.ietf.org/doc/draft-fang- > vpn4dc- > > > > > problem-st > > > > > atement > > > > > Htmlized: http://tools.ietf.org/html/submission.filename > }}- > > > 01 > > > > > Diff: http://tools.ietf.org/rfcdiff?url2=draft-fang- > > > > vpn4dc- > > > > > problem > > > > > -statement-01 > > > > > > > > > > Abstract: > > > > > Network Service Providers commonly use BGP/MPLS VPNs [RFC > 4364] > > > as > > > > > the control plane for virtual networks. This technology has > > > proven > > > > > to scale to a large number of VPNs and attachment points, > and it > > > > is > > > > > well suited for Data Center connectivity, especially when > > > > > supporting all IP applications. > > > > > > > > > > The Data Center environment presents new challenges and > imposes > > > > > additional requirements to IP VPN technologies, including > multi- > > > > > tenancy support, high scalability, VM mobility, security, > and > > > > > orchestration. This document describes the problems and > defines > > > > the > > > > > new requirements. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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
