Subject: Re: vpn4dc Q&A

From: Robert Raszuk <[email-masked]>
Date: Tue, 01 Nov 2011 13:30:34 +0100

Hi Luyuan,

> 1 What are we trying to achieve in vpn4dc?
>
> - DC Host-to-host connectivity through layer 3 signaling
> protocols.

I think before we start talking about signalling we need to seriously 
discuss auto-discovery. Static model of manual provisioning of VPN sites 
will not address DC host to host connectivity requirements.

> 2. What cannot be achieved through L3VPN today?
>
>          - We don't have a stds way for host-to-host vpn connectivity
> through protocols signaling which easily work in DC.
>
>         - BGP/MPLS VPN is extremely successful in network environment.
> But it is normally not accepted in the computing community. I had
> discussion with folks working on DC directly or indirectly, including
> Google, Yahoo, Facebook, VZ, AT&T, CenturyLink, T-Systems, ... many
> folks think layer 3 is a scalable approach, but no BGP/MPLS VPN inside
> DC, into host... so we need to bridge the gap.
>
>        - And this is no long SP provisioned vpns, it has wider scope.

L3VPNs were indeed successful to interconnect static VPN sites. L3VPNs 
however hardly fit the model of interconnection of hosts or mobile 
devices like smartphones to be part of same VPN. The reason is that site 
discovery does not exits in L3VPN. The L3VPN discovery is limited to SP 
network among SP provisioned sites. That is not sufficient to the set of 
requirements at hand.

> 3. What is missing?
>
>       The missing piece is the segment in DC and
> inter-connection/auto-mapping of the DC segment to the network segment.

One could argue if that is at all required. It is only required to add 
DC to traditional L3VPNs or statically build VPNs between VMs residing 
on hosts owned by given customer. I do not think that this accurately 
reflects the customers flexible computing requirements of today.

> 4. Is this IETF problem?
>
> - Yes. It is about IP protocols for establish connectivity.

Agreed.

> 5. Who wants this?
>
> Please speak out if you do.

I think we need more that this. I want to be able to access VPN 
resources on demand both in the sites of my company as well as in their 
both private and public data centers. And this is all from android or 
iphone regardless if I am at home or in the plane.

I also need to be able to dynamically shop of computing resources among 
public clouds when I encounter increased processing demands.

> 6. What are not in scope for this initiative/charter?
>
> - L2VPN for DC connectivity - that goes to L2VPN WG

I do not think we need to have different solutions to different types of 
VPNs. If you think about the problem space it should be one button to 
switch from L3VPN to L2VPN and not a different IETF WG.

> - Encryption, key management, new authentication protocols - these go to
> Security Area.

Disagree.

> - Multicast - the mcast use in DC need to be further studied. We like to
> start without mcast to make things simpler, be able to move.

I agree.

Thx,
R.

---

From: Lucy yong <[email-masked]>
Date: Tue, 01 Nov 2011 15:30:59 +0000

Please see my comments below.
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Luyuan Fang (lufang)
Sent: Tuesday, November 01, 2011 12:06 AM
To: L3VPN
Subject: vpn4dc Q&A

Hi all,

There are a few things around vpn4dc I'd like to kick off the discussion.
I put my simple answers to each question, very much like to hear yours.

-          DC Host-to-host connectivity through layer 3 signaling protocols.
       These hosts can be in SP DC, Enterprise DC, content provider's DC, any DC... The connection can be in the same DC, or different DCs within any admin domains.
[[LY]] Agree. There are many ways to form a hosts' private virtual network: via L3VPN, L2VPN, overlay VPN, or hybrid of them. My understanding is VPN4DC aiming on L3VPN solution because SPs have business cases on it, and it makes the work scope very clear.

2. What cannot be achieved through L3VPN today?
        - We don't have a stds way for host-to-host vpn connectivity through protocols signaling which easily work in DC.
       - BGP/MPLS VPN is extremely successful in network environment. But it is normally not accepted in the computing community. I had discussion with folks working on DC directly or indirectly, including  Google, Yahoo, Facebook, VZ, AT&T, CenturyLink, T-Systems, ... many folks think layer 3 is a scalable approach, but no BGP/MPLS VPN inside DC, into host... so we need to bridge the gap.
      - And this is no long SP provisioned vpns, it has wider scope.
[[LY]] Today L3VPN provides the connectivity among the connected sites, or say DC sites but it does not have the control on the hosts at the sites. VPN4DC requires the admission control on host joining/leaving via in-band signaling.

3. What is missing?
     The missing piece is the segment in DC and inter-connection/auto-mapping of the DC segment to the network segment.
[[LY]] VPN4DC does not have any assumption in DC now. Thus, it addresses some use case, but not all. It makes the problem clear in this way.

4. Is this IETF problem?
[[LY]] agree.

5. Who wants this?

6. What are not in scope for this initiative/charter?
- L2VPN for DC connectivity - that goes to L2VPN WG
- Encryption, key management, new authentication protocols - these go to Security Area.
- Multicast - the mcast use in DC need to be further studied. We like to start without mcast to make things simpler, be able to move.

Looking forward seeing  your comments to any of the questions.

Thanks,
Luyuan

---

From: Yiqun Cai <[email-masked]>
Date: Tue, 01 Nov 2011 11:17:29 -0700

> start without mcast to make things simpler, be able to move.

If we expect this work to be successful, and if past history is any
indication of what might happen in the future, the moment the solution gets
deployed people will ask for multicast.  Excluding multicast would be a
costly mistake for everyone.

When multicast was forgot, or declared out of scope, we ended up spending
more time to "fix" it.  I am sure all of us still have fresh memory of what
l3vpn has been doing since 2004.  And in case you are not aware, there is a
brand new BOF dedicated to solving v4/v6 transition for multicast.

When multicast was considered from the beginning, (e.g., trill and l2vpn)
the work is still there but there is less drama.

Given the nature of the proposed work and its applicable space,  I just
don't see how you can avoid multicast down the road.

-- 
Yiqun

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 1 Nov 2011 13:26:43 -0500

Yiqun,

My fear (and a few others' interested in this work) is that if we start
it with mcast, we might just end with not going anywhere by looking the
history of past many years with mvpn. 

On the other hand, I'm open to the folks who operate DC to say they must
have mcast. 

Luyuan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yiqun Cai (ycai)
> Sent: Tuesday, November 01, 2011 2:17 PM
> To: L3VPN
> Subject: Re: vpn4dc Q&A
> 
> 
> 
> >
> > - Encryption, key management, new authentication protocols - these
go
> to
> > Security Area.
> >
> > - Multicast - the mcast use in DC need to be further studied. We
like
> to

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 1 Nov 2011 14:30:47 -0400

> On the other hand, I'm open to the folks who operate DC to say they must

Are there any drafts now extant that cover multicast for VPN4DC ?

Regards
Marshall

---

From: Pedro Marques <[email-masked]>
Date: Tue, 1 Nov 2011 11:39:36 -0700

Yiqun,
There are two different aspects to "multicast".
  - The service: allowing IP applications to send packets to a group
of addresses.
  - Network state: having IP group state in network devices in the
middle of the network.

The first (application service) is not commonly offered, in public
data-centers. Applications do not rely on it and use different
strategy for discovery and content distribution.

The second has very significant scaling and operational challenges at
large scale. Specially if you consider the topology of a DC network.

One can offer a "multicast" service via ingress replication or by
using replication servers in a tree. The latter approach (tree of
replicators) can be implemented on top of a unicast service for those
apps that are looking for a discovery service. But there are simpler /
more effective ways to provide discovery.

regards,
  Pedro.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 01 Nov 2011 19:49:50 +0100

Hi Yiqun,

I think the priority given to support multicast really depends on the 
planned scope of given VM to VM data exchange models.

I could easily see large use cases for non-multicast enabled secured 
inter-VM or VM to end user connectivity.

Especially in cases where VM to VM connectivity is not locked to 
particular service provider support of real multicast may as Pedro just 
observed performed by ingress replication.

Alternatively other ways to efficiently distribute content could be 
utilized in the application space.

Best,
R.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 1 Nov 2011 15:33:59 -0400

> more effective ways to provide discovery.

If there is any significant video transport, and in particular if IPTV
services are being offered, multicast is going to become an issue.
I believe that is what drove  the Multicast VPN work at L3VPN originally.

Regards
Marshall

---

From: Pedro Marques <[email-masked]>
Date: Tue, 1 Nov 2011 13:02:23 -0700

Marshall,
Content delivery networks are a very interesting topic but i believe
orthogonal to the "DC" conversation.

My understanding (probably an urban myth) is that the main driver
behind l3vpn multicast support was "stock ticker" style applications.
i.e. non-guaranteed delivery of repeated information in which the
sender explicitly doesn't want to control the order of the receivers.

That functionality can be supported via a tree of replication servers.
The most important characteristic is probably that the sender doesn't
control order.

  Pedro.

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 1 Nov 2011 17:40:53 -0500

Rob,

Thanks for your comments, see in-line.

> From: Robert Raszuk [mailto:[email-masked]]
> Sent: Tuesday, November 01, 2011 8:31 AM
> To: Luyuan Fang (lufang)
> Cc: L3VPN
> Subject: Re: vpn4dc Q&A
> 
> Hi Luyuan,
> 
Good point.

> network among SP provisioned sites. That is not sufficient to the set
We are in agreement here. 
When we said to bridge the gap, it did not mean to push BGP/MPLS VPN all
the way to the host, VMs.

> > - Yes. It is about IP protocols for establish connectivity.
Thx.
> switch from L3VPN to L2VPN and not a different IETF WG.
I agree with the points you are making.

But I don't think it works for the charter scope to cover all,
especially L2VPN recently explicitly added DC solution in the charter,
NOV3 also going L2VPN to discuss. There also different set of focus in
dealing with IEEE bridges, ARP scaling, etc. in l2. which may not apply
in l3. 

I prefer to keep this charter as l3 only. More manageable  to progress
the work, and avoid overlapping.

It is a good point you made on "one button to switch from L3VPN to
L2VPN", I am sure there are many places we need to align effort between
l3, l2, and sdn too. 

go
like
> > start without mcast to make things simpler, be able to move.
Thx.

Luyuan

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 1 Nov 2011 17:45:52 -0500

Lucy,

Thanks for commenting, I'm good with your points.

Luyuan

From: Lucy yong [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2011 11:31 AM
To: Luyuan Fang (lufang); L3VPN
Subject: RE: vpn4dc Q&A

Lucy

Of Luyuan Fang (lufang)

Hi all,

There are a few things around vpn4dc I'd like to kick off the
discussion.

       These hosts can be in SP DC, Enterprise DC, content provider's
DC, any DC... The connection can be in the same DC, or different DCs
within any admin domains.

[[LY]] Agree. There are many ways to form a hosts' private virtual
network: via L3VPN, L2VPN, overlay VPN, or hybrid of them. My
understanding is VPN4DC aiming on L3VPN solution because SPs have
business cases on it, and it makes the work scope very clear. 

[[LY]] Today L3VPN provides the connectivity among the connected sites,
or say DC sites but it does not have the control on the hosts at the
sites. VPN4DC requires the admission control on host joining/leaving via
in-band signaling. 

3. What is missing?

[[LY]] VPN4DC does not have any assumption in DC now. Thus, it addresses
some use case, but not all. It makes the problem clear in this way.

4. Is this IETF problem?

[[LY]] agree.

5. Who wants this? 

Thanks,

Luyuan

---

From: Yiqun Cai <[email-masked]>
Date: Tue, 01 Nov 2011 16:06:29 -0700

Luyang, Pedro, Robert,

If I understand your replies correctly,  what you are saying is not that
"multicast is out of scope".  Rather,  it is that if there is the need to do
multicast, whether at application or IP layer, and whether from within the
data center or inside the networks that connect the data centers, it will be
addressed by unicast replication.

If that is the point, then we should say it explicitly.

Thanks.

-- 
Yiqun

---

From: Pedro Marques <[email-masked]>
Date: Tue, 1 Nov 2011 16:38:26 -0700

Yiqun,

My opinion is that:
  - It is unclear if an IP multicast service to applications is a
requirement. As i mentioned both discovery and reliable content
distribution tend to be done today without IP multicast service to
applications.
  - Storing IP multicast state in the middle of the network is very
likely problematic at the scale required for this class of solutions.
A solution for network virtualization must be able to work without
storing multicast state in routers and switches.
  - If it becomes desirable to offer an IP multicast service, for
instance because the order of delivery is now no longer controllable
by the application, that can be offered as an overlay on top an
unicast service.

Thus i disagree with your assement that multicast needs to be part of
the DC solution from the start. On the other hand, the people
interested in discussing multicast solutions should have have a forum
in the l3vpn WG since it is already covered in the charter.

  Pedro.

---

From: Yiqun Cai <[email-masked]>
Date: Tue, 01 Nov 2011 17:47:51 -0700

> distribution tend to be done today without IP multicast service to

Pedro,

There are applications that are built on multicast. IPTV is one. Market data
(including what you referred to as "stock ticker" earlier) is another, both
and others are what drive multicast in l3vpn.

When IP multicast connectivity is not available but abundant bandwidth is,
one might choose to use unicast to support these applications.  But that is
a different story.

We can argue on the percentage of multicast traffic v.s., unicast in any
particular network.  But in quite a few networks, the percentage number is
not zero.

> likely problematic at the scale required for this class of solutions.

I'm not sure I agree.  But that is ok.

> storing multicast state in routers and switches.

In fact I'm quite fine with the above statement (even though I don't
necessarily agree with how you get there).  Requirement and solution -wise,
unicast replication can indeed be a common denominator.  However, merely
declaring that multicast is "out of scape" will likely get us into trouble
down the road.  That was my point.

-- 
Yiqun

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 1 Nov 2011 21:22:17 -0500

Yiqun,

My thinking is that we leave mcast out for the initial phase of the project unless we see strong DC demand for it.

This is not a typical SP network environment we are looking at. E.g., we know that often DC folks choose to use N*end systems to protect against failure rather than using multi-homing redundancy protocols already exist in the network world - they try to avoid complexity. 

I would not say no one needs multicast in DC, I'm sure the questions would be raised again and again.

The trade off in design consideration is optimal design vs. simplicity. DC folks are often prefer the later.

The trade off in deciding the charter scope between being complete, but may not get there in 3 years vs. not perfect, not covering 100% of the cases, but something useful can come out relatively quickly to serve large number of end users who are in need. I prefer the later.

Thanks,
Luyuan

> Sent: Tuesday, November 01, 2011 8:48 PM
> To: Pedro Marques
> Cc: L3VPN; Robert Raszuk
> Subject: Re: vpn4dc Q&A
> 
> 
> 
> 
> like to

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 1 Nov 2011 22:34:57 -0400

Dear Pedro;

> in the l3vpn WG since it is already covered in the charter.

Yes, they do. As it happens, this is it.

Regards
Marshall