Derick,

Thank you for clarifying it for me.  Yes, I have seen network built like what you described.  It is indeed a valid use case.  However, things gets really complicated when you throw Inter-AS into the mix.  IETF works on baby steps with clearly and precisely defined problems.  We have been given a directive to define and reach consensus on a base set of problem statement.  I am afraid that the situation you are describing may be out-of-the-scope for this stage, IMHO.  However, it can certainly be something of interest for the next stage.  

Currently there are three separate problem statement drafts in VPN4DC, and many other drafts also described some problems in detail.  We would like to summarize the problems into a common set to help define our working charter and scope.  Luyuan will send something out next week to kick start this effort.  Please feel free to comment and/or voice your opinion agree or disagree.  


 
Best regards,
 
Ning So
Verizon Corporate Technology
(office) 972-729-7905
(Cell) 972-955-0914
 
Subject: 
Message-ID:
	<1319517945.99929.YahooMailNeo@web161805.mail.bf1.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"

Ning:

-----
Another applicable type of environment are "<blank>-service-providers"...

[Ning] Can you gave an example to help me understand it better?

-----


For instance, there are SIP/VoIP providers who do not own a regional or nation-wide MPLS transport network used primarily as revenue-generating L3VPN services network (such as Verizon, ATT, etc have). ?I have seen in a number of networks where these type of providers would purchase a DS3 or ethernet circuit from Verizon or ATT and channelize it with PVCs or VLANs. ?Each PVC or VLAN would correspond to ?a different L3VPN network (i.e., customer) on Verizon or ATT's MPLS network. ?The SIP/VoIP provider would then use Inter-AS Option A to connect these L3VPN networks to L3VPN networks they have built for their external customers in their data center. ?They are effectively extending these L3VPNs into their datacenter to attach (and customize) services to them. ?In some cases customer owned appliances are put "in the path" of the customer's traffic in the provider's data center. ?

There are SIP, Storage, and E-mail providers (all fairly obvious) that I am aware of doing this. ?Less obvious are more specialized services like financial services and applications and medical applications and services. ?Locally here I have run into at least one company delivering video and audio in this fashion for businesses that want streaming advertisements on media displays. ?

Of course, in order to maximize their potential customer base they connect to multiple carriers in this way. ?

The point though is that this is an example of a non-transport service-provider attaching VMs and other hosts/appliances/services ultimately to customer L3VPNs internal to the provider's datacenter. ?There is a ?need for automating the turn up of VPNs (as one of the VPN4DC drafts describe) on the PEs facing the external transport providers with which they are running Inter-AS option A, as well as on the PEs facing the VM hosts or virtualized appliances. ?Also there is a need for ?automatically building a VM or a virtual-appliance on the fly for service to that VPN. ?

Sorry if this is too verbose or not clear enough. ?Here is a partial diagram:?http://packetpushers.net/extending-private-networks-into-your-datacenter/. ?Now just imagine a PE in the data center with VMs attached to it for each of the four VRFs.

Derick







From: "So, Ning" <ning.so@verizon.com>
To: "l3vpn@ietf.org" <l3vpn@ietf.org>
Sent: Monday, October 24, 2011 10:50 PM
Subject: RE: Re: Discussion of VPN4DC drafts

Derick,

Please see my comments in-line.

?
Best regards,
?
Ning So
Verizon Corporate Technology
(office) 972-729-7905
(Cell) 972-955-0914
?
Date: Mon, 24 Oct 2011 17:12:39 -0700 (PDT)
From: Derick Winkworth <ccie15672@yahoo.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>,??? L3VPN WG mailing list
??? <l3vpn@ietf.org>
Subject: Re: Discussion of VPN4DC drafts
Message-ID:
??? <1319501559.87264.YahooMailNeo@web161802.mail.bf1.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"

All:

I think the drafts constitute a great start to addressing this gap. ?

My first, perhaps superficial, observation is that much of the language is geared towards "Service-Provider." ?I think in the context of VPNs for Data Centers, these drafts apply equally to multi-security zone Data Centers in non-SP networks that have multiple logically isolated network segments. ?For instance, multiple DMZs, server farms, storage networks, corporate LANs, guest LANs, etc. ?These could very well all be L3VPNs in an MPLS infrastructure that interconnects and extends into the various data centers of an enterprise network. ?The kind of security and transparency that the infrastructure provides is adequate for the purpose of passing audits (where the alternative must be physical separation of network resources). ?There is certainly more enterprise adoption of MPLS happening in the field today for this purpose.

[Ning] Agree.

Another applicable type of environment are "<blank>-service-providers" that provide various IP enabled applications and services to the private networks of external customers. ?These environments are not classic service-providers because they do not own transport networks. ?They connect to multiple carriers to have reachability to as many potential customers' private networks as possible. In this case they are extending customer's private networks into their data centers in a secure/transparent way, similar to the description in some of the drafts for VPN4DC.

[Ning] Can you gave an example to help me understand it better?

I think it might be possible to generalize VPN4DC so that its inclusive of these situations. To be clear, these scenarios involve companies who are not classic "service-providers" but are running their own MPLS network with P and PE nodes and not just buying L3VPN sevices from an external provider. ?Rather than framing everything in a "service-provider" or "enterprise" context, we could just frame it in general networking terms. ?

[Ning] Service provider and Enterprise are meant to be generic terms, and I agree with you that they are not good terms to fit the situation you are describing.? I can certainly go back to make the term more generalized (or at least clearly defined in definition section). 

I think there is a sort of Hegelian synthesis happening in the industry between service-provider and enterprise, and VPN4DC is a clear bridge between them.

[Ning] Agree.? 

Thanks.

Derick


________________________________
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
To: L3VPN WG mailing list <l3vpn@ietf.org>
Sent: Monday, October 24, 2011 6:35 PM
Subject: Discussion of VPN4DC drafts 

Colleagues,

A number of drafts related to the VPN4DC topic are now available in the Internet-Draft repository. The ones I could fine are listed below.

When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was conditional on the basis that:

1) There needed to be viable -00 drafts before the cutoff.
2) The problem needed to be discussed prior to Taipei on the L3VPN list.

To date there has not been much discussion of VPN4DC on the L3VPN list, possibly because folks were waiting for -00 drafts to be published.

Now that a number of drafts have been published I would encourage those folks interested in the VPN4DC topic to discuss the various drafts on the L3VPN list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancelled.

The VPN4DC related drafts that I could find (there may be others that I've missed) are:

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00

L3VPN automatical interconnection for VPN4DC
http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00

Requirements of Layer 3 Virtual Private Network for Data Centers
http://tools.ietf.org/html/draft-so-vpn4dc-00

L3VPN Protocol Gap Analysis for Data Centers
http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00

Experiment of Example Solution for VPN4DC
http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00

End-system support for BGP-signaled IP/VPNs.
http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02

Problem Statement for Dynamic Secure Interconnect
http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/l3vpn/attachments/20111024/38f215cb/attachment.htm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/l3vpn/attachments/20111024/074c2ea9/attachment.htm>

------------------------------

_______________________________________________
L3VPN mailing list
L3VPN@ietf.org
https://www.ietf.org/mailman/listinfo/l3vpn


End of L3VPN Digest, Vol 88, Issue 18
*************************************