Subject: I-D Action: draft-ietf-l3vpn-end-system-01.txt

From: [email-masked]
Date: Mon, 01 Apr 2013 15:46:01 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF.

	Title           : BGP-signaled end-system IP/VPNs.
	Author(s)       : Pedro Marques
                          Luyuan Fang
                          Ping Pan
                          Amit Shukla
                          Maria Napierala
                          Nabil Bitar
	Filename        : draft-ietf-l3vpn-end-system-01.txt
	Pages           : 21
	Date            : 2013-04-01

Abstract:
   This document describes a solution in which the control plane
   protocol specified in BGP/MPLS IP VPNs [RFC4364] is used to provide a
   Virtual Network service to end-systems.  These end-systems may be
   used to provide network services or may directly host end-to-end
   applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-l3vpn-end-system-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Saku Ytti <[email-masked]>
Date: Tue, 2 Apr 2013 12:36:24 +0300

- External VPN forwarder at page 12 appears not to support QinQ, should it?

- Draft seems IPv4 centric, with static /32 often appearing, while
IPv6 support is explicitly mentioned.

- Draft mentions GRE and MPLS supported, but most examples speak as if
it's always GRE encapsulated.
   It's not clear to me how VPN forwarder would connect via MPLS to a
P or PE node, where would IGP label come.
   Or should  end-system route server<->PE have OptB? (Would also give
label security, so VPN forwarder would not need to be fully trusted)

-- 
  ++ytti

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Apr 2013 12:42:04 +0200

Hi Saku,

Let me provide some of my comments ...

Do you have in mind sort of CSC analogy that tenants internally have their
own demux based on bottom 802.1Q tag  while top one would be used just like
a single VLAN tag as described ? 

> IPv6 support is explicitly mentioned.

I think you can build IPv6 DC virtualization services while still using
IPv4 only DC core. 

> label security, so VPN forwarder would not need to be fully trusted)

The translation happens at the option B ASBR. I would not really run MPLS
LDP + IGP or IGP with extension to carry labels or other form of tags in
the DC.

In fact having high speed IP core which is non blocking should be basic
principle of the design.

Personally I like Petr's draft:
http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-03

Best,
R.

---

From: Saku Ytti <[email-masked]>
Date: Tue, 2 Apr 2013 14:48:40 +0300

On (2013-04-02 12:42 +0200), Robert Raszuk wrote:

Hi Robert,

> a single VLAN tag as described ? 

I'm thinking if 'VPN forwarder' is catering to many hosts, I might want in
L2 to have top tag for host and bottom tag for guest. If XMPP just allows
single tag, it may exclude external VPN forwarder or at least limit its
scale.
But maybe that is intentional, to steer away from external VPN forwarder in
large-scale deployments.

> I think you can build IPv6 DC virtualization services while still using

I was just worried as draft specifically allows for IPv6, yet XMPP messages
seem to be trailed with /32. I'm personally not interested much in
dual-stack control-plane. I'm happy to run 6PE now, and maybe in future go
IPv6 only control-plane and 4PE for legacy. But I understand it might not
be popular position.

> LDP + IGP or IGP with extension to carry labels or other form of tags in

Fully agreed. I could see myself running this draft, but I would not want
to trust 'VPN forwarder' fully, so OptB with appropriate implementation
which actually does implement label checking would be requirement for me.

> http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-03

I'll have to read it, thanks.

-- 
  ++ytti

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Apr 2013 14:47:13 +0200

Hi Saku,

> single tag, it may exclude external VPN forwarder or at least limit its

Oh I see ... it could be a valid case. But I am not sure why in this case
we could not just have flat single VLAN tagging for guests between hosts
and external VPN forwarder. Would you expect more then 4K (VLAN limit) to
be exceeded ? If not I guess there is no good reason for QinQ.

In fact if you have QinQ there the semantics of VPN label used by such VPN
forwarder would need to include direct demux for both VLAN tags wouldn't it
?

Cheers,
R.

---

From: Saku Ytti <[email-masked]>
Date: Tue, 2 Apr 2013 16:12:04 +0300

> be exceeded ? If not I guess there is no good reason for QinQ.

4k guests doesn't sounds like particularly large number of guests in
external VPN forwarder scenario. Maybe I have 50 hosts with 100 guests each
in my L2?

> forwarder would need to include direct demux for both VLAN tags wouldn't it

Yes. Your server->network lookup key would be two VLANs, result would be
label + oif.  network->server lookup key would be label, result would be
two VLANs + oif.

-- 
  ++ytti

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Apr 2013 15:21:23 +0200

> external VPN forwarder scenario. Maybe I have 50 hosts with 100 guests each
Sure, but my question was would all of them go via single external VPN
forwarder ? If you isolate L2 domains between hosts and VPN forwarders you
can have obviously much larger DC ...

Cheers,
R.

---

From: Saku Ytti <[email-masked]>
Date: Tue, 2 Apr 2013 16:49:52 +0300

> can have obviously much larger DC ...

I don't know if anyone would wish to cater more than 4k guests via single
external VPN forwarder, it just sounds like quite low number to me.
But maybe it is sufficient in practical deployments. And I guess
green-field would have local VPN forwarder anyhow.

-- 
  ++ytti

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 2 Apr 2013 10:57:42 -0700

> - External VPN forwarder at page 12 appears not to support QinQ, should it?

The document describes the behavior of the end-system and the external Forwarder. In my mind, the scenario where Q-in-Q (or other L2 encap) is used between the end-system and the Forwarder because of additional L2 hops should not need to be explicitly described.

> IPv6 support is explicitly mentioned.

Searching thought the document /32 seems to appear in examples. If you don't mind pointing out explicitly where you believe the text should be corrected, i would appreciated (private email is ok).

> it's always GRE encapsulated.

MPLS over GRE or MPLS over UDP are used currently. MPLS over ethernet directly would require the end-system to participate in the IGP and have LDP enabled which is not to my knowledge a practical scenario.

> label security, so VPN forwarder would not need to be fully trusted)

The route-server is not on the forwarding path.
The data-center gateway typically implements option B (or IBGP plus next-hop self) and stitches the MPLS-over-GRE LSP segment (internal to the DC) with an MPLS over L2 LSP segment outside the data-center, in scenarios where the service is delivered to a WAN L3VPN.

---

From: Saku Ytti <[email-masked]>
Date: Wed, 3 Apr 2013 09:10:49 +0300

On (2013-04-02 10:57 -0700), Pedro Roque Marques wrote:

> The document describes the behavior of the end-system and the external
> Forwarder. In my mind, the scenario where Q-in-Q (or other L2 encap) is
> used between the end-system and the Forwarder because of additional L2
> hops should not need to be explicitly described.

I don't understand. Are you saying even if host would double tag, that
would not be relevant to Forwarder? Looking at page 12 I don't know how to
signal two tags to Forwarder.

> Searching thought the document /32 seems to appear in examples. If you
> don't mind pointing out explicitly where you believe the text should be

I'm probably reading it wrong, page 13, request 2, associate node is one
that caught my eye.

> The route-server is not on the forwarding path.

I was thinking native MPLS-to-the-edge in DC, where I only have VPN
Forwarder between my host and core MPLS PE (preferably right in the host as
'virtual router'). Then if I'd use OptB, I'd need to collapse route-server
and VPN forwarder into same box?

> The data-center gateway typically implements option B (or IBGP plus
> next-hop self) and stitches the MPLS-over-GRE LSP segment (internal to
> the DC) with an MPLS over L2 LSP segment outside the data-center, in
> scenarios where the service is delivered to a WAN L3VPN.

Would this be true for green-field as well? I'd really love to see solution
where I can plug host anywhere in MPLS network.

-- 
  ++ytti

---

From: "George, Wes" <[email-masked]>
Date: Mon, 8 Apr 2013 14:38:16 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Saku Ytti
> Sent: Tuesday, April 02, 2013 7:49 AM
> To: L3VPN
> Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt
>
> I was just worried as draft specifically allows for IPv6, yet XMPP
> messages seem to be trailed with /32. I'm personally not interested much
> in dual-stack control-plane. I'm happy to run 6PE now, and maybe in
> future go
> IPv6 only control-plane and 4PE for legacy. But I understand it might
> not be popular position.
>

[WEG] +1
in fact, at the Orlando IETF meeting, I and a few others kicked off a discussion in MPLS WG regarding a gap analysis for IPv6-only operation of MPLS features, because we believe that this will be necessary within the time horizon for IETF work. So the authors would do well to consider and document or resolve any IPv4 dependencies. While obviously, MPLS control plane dependencies must be solved first, anything specific to this implementation that relies on IPv4 to function should be noted.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.