Subject: RE: Re: Discussion of VPN4DC drafts

From: "So, Ning" <[email-masked]>
Date: Mon, 24 Oct 2011 23:50:40 -0400

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 <[email-masked]>
To: Ben Niven-Jenkins <[email-masked]>,	L3VPN WG mailing list
	<[email-masked]>
Subject: Re: Discussion of VPN4DC drafts
Message-ID:
	<[email-masked]>
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 <[email-masked]>
To: L3VPN WG mailing list <[email-masked]>
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>

---

From: Derick Winkworth <[email-masked]>
Date: Mon, 24 Oct 2011 21:45:45 -0700 (PDT)

Ning:

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

-----

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" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Monday, October 24, 2011 10:50 PM
Subject: RE: Re: Discussion of VPN4DC drafts

Derick,

Best regards,
 
Ning So

All:

[Ning] Agree.

[Ning] Agree.  

Thanks.

Derick

Colleagues,

VPN4DC Problem Statement

VPN4DC Problem Statement

Ben

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 25 Oct 2011 02:45:51 -0500

Derick,

I think you are right about a lot of focus on service provider in many
cases, and indeed we have many SP contributors. J

But our intention, at least from my end, was to cover the DC/Cloud VPN
in general, including network service providers, content providers, and
Enterprises. E.g. draft-fang-vpn4dc-problem-statement-00.txt is general
in scope.

You brought up a lot of good points and very useful examples. Would you
mind to turn these use cases into a Use Case draft? 

It does not need to be comprehensive covering all cases. We could have
separate documents each covering different type of cases. We could also
consolidate them together later. The format is less important than the
content.

Thanks,

Luyuan

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Derick Winkworth
Sent: Tuesday, October 25, 2011 12:46 AM
To: [email-masked]
Subject: Re: Re: Discussion of VPN4DC drafts

Ning:

-----

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

-----

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

 

Derick,

Best regards,
 
Ning So
 
To: Ben Niven-Jenkins <[email-masked]>,    L3VPN WG mailing
list

All:

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.

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

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:

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

VPN4DC Problem Statement

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