Subject: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Jun 2013 13:57:16 +0200

WG,

He have published a new draft in SOFTWIRE describing how a Lightweight 
4over6 CPE can use PCP for provisioning. It makes use of the PORT_SET 
extension.

In this WG we're looking for feedback specific to our proposed usage of 
PCP. Is it correct or is it fatally flawed? Could it be improved? 
Anything PCP-specific that we should have considered?

If you would like to comment on the high-level softwire framework, 
please use [email-masked] instead.

Thanks,
Simon

-------- Message original --------
Sujet: New Version Notification for 
draft-perreault-softwire-lw4over6-pcp-00.txt
Date : Tue, 04 Jun 2013 01:54:06 -0700
De : [email-masked]
Pour : Chongfeng Xie <[email-masked]>, Cathy Zhou 
<[email-masked]>, Simon Perreault <[email-masked]>

A new version of I-D, draft-perreault-softwire-lw4over6-pcp-00.txt
has been successfully submitted by Chongfeng Xie and posted to the
IETF repository.

Filename:	 draft-perreault-softwire-lw4over6-pcp
Revision:	 00
Title:		 Provisioning Lightweight 4over6 (lw4o6) with the Port Control 
Protocol (PCP)
Creation date:	 2013-06-03
Group:		 Individual Submission
Number of pages: 6
URL: 
http://www.ietf.org/internet-drafts/draft-perreault-softwire-lw4over6-pcp-00.txt
Status: 
http://datatracker.ietf.org/doc/draft-perreault-softwire-lw4over6-pcp
Htmlized: 
http://tools.ietf.org/html/draft-perreault-softwire-lw4over6-pcp-00

Abstract:
    This memo defines the procedures that a Lightweight B4 uses for
    provisioning its parameters with the Port Control Protocol.

The IETF Secretariat

---

From: <[email-masked]>
Date: Thu, 6 Jun 2013 09:42:31 +0200

Hi Simon,

I suggest pcp for lw4o6 to follow the some design choices as those of ds-lite. In particular:
* adopt the plaine IPv6 mode which is currently supported by various vendors.
* use the updated server discovery procedure (if no pcp server is explicitly configured, use the lwAFTR as pcp server instead of the default router).

It would be useful to include a section to discuss the behavior of the PCP server. The server may be tweaked to accept only MAP with PORT_SET. Other options and OpCodes can be disabled.

On the client side, you may indicate there is no need to include THIRD_PARTY, PREFER_FAILURE and FILTER options in MAP requests.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de Simon
>Perreault
>Envoyé : mardi 4 juin 2013 13:57
>À : [email-masked]
>Objet : [pcp] Fwd: New Version Notification for draft-perreault-softwire-
>lw4over6-pcp-00.txt
>
>WG,
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Jun 2013 10:01:58 +0200

Le 2013-06-06 09:42, [email-masked] a écrit :
> I suggest pcp for lw4o6 to follow the some design choices as those of
> ds-lite. In particular: * adopt the plaine IPv6 mode which is
> currently supported by various vendors.

I'm well aware of this, but it is problematic.

Consider the use case of a load-balanced lwAFTR. The load balancing is
based on L4 hashing. You have a bunch of IPv4-over-IPv6 tunnels being
load-balanced this way over a bunch of lwAFTRs. For those tunnel, the L4
hash is calculated over a 3-tuple: source IPv6 address, destination IPv6
address, and protocol number. No port numbers are available to build a
5-tuple.

Now, you want PCP to be load-balanced to the same lwAFTR as the 
IPv4-over-IPv6 tunnel. With the plain IPv6 mode, that's not going to 
work since the PCP flow will be hashed on the UDP 5-tuple. The way to 
ensure that the PCP traffic reaches the correct lwAFTR is to put PCP 
inside the tunnel.

So that's the problem we have. Solution ideas would be much appreciated.

> * use the updated server discovery procedure (if no pcp server is
> explicitly configured, use the lwAFTR as pcp server instead of the
> default router).

Right, that would follow if we used the plain IPv6 mode.

> It would be useful to include a section to discuss the behavior of
> the PCP server. The server may be tweaked to accept only MAP with
> PORT_SET. Other options and OpCodes can be disabled.

Sure. If you could send text that would be great.

> On the client side, you may indicate there is no need to include
> THIRD_PARTY, PREFER_FAILURE and FILTER options in MAP requests.

Good suggestion.

Isn't THIRD_PARTY needed with plain IPv6 mode?

Simon

---

From: <[email-masked]>
Date: Thu, 6 Jun 2013 10:17:16 +0200

Re-,

Please see inline.

Cheers,
Med

>De : Simon Perreault [mailto:[email-masked]]
>Envoyé : jeudi 6 juin 2013 10:02
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]
>Objet : Re: [pcp] Fwd: New Version Notification for draft-perreault-
>softwire-lw4over6-pcp-00.txt
>
[Med] This is deployment-specific. The hash computation can be updated to rely on IP-based information, no port numbers would be needed.

>ensure that the PCP traffic reaches the correct lwAFTR is to put PCP
[Med] Load-balancing can be achieved in various manners. Another scheme would be to avoid the use of anycast-based LB but dispatch CPE to the enabled lwAFTR by returning unicast addresses.

>Sure. If you could send text that would be great.
[Med] Ok, I will do.

>Isn't THIRD_PARTY needed with plain IPv6 mode?
[Med] Unlike DS-Lite case for which THIRD_PARTY is needed to successfully do NAT in the AFTR, the lw4o6 only requires the IPv6@ of the lwB4 and not the internal IPv4 address. This another reason to adopt the plain IPv6 mode. The binding table will associate an IPv6@ with {IPv4@, Port Set}.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Jun 2013 10:24:47 +0200

Le 2013-06-06 10:17, [email-masked] a écrit :
> [Med] Unlike DS-Lite case for which THIRD_PARTY is needed to
> successfully do NAT in the AFTR, the lw4o6 only requires the IPv6@ of
> the lwB4 and not the internal IPv4 address. This another reason to
> adopt the plain IPv6 mode. The binding table will associate an IPv6@
> with {IPv4@, Port Set}.

How would the PCP server know the difference between a request for an 
internal IPv4 mapping and a request for an internal IPv6 mapping if both 
are sent over IPv6 and there is no THIRD_PARTY option? I mean, the CPE 
could want to use PCP to control an plain IPv6 firewall for example. Do 
you mean that all requests sent to the lwAFTR IPv6 address will 
implicitly be IPv4 internal? That seems like a dangerous assumption to me...

Simon

---

From: <[email-masked]>
Date: Thu, 6 Jun 2013 10:37:25 +0200

>Envoyé : jeudi 6 juin 2013 10:25
>are sent over IPv6 and there is no THIRD_PARTY option?

[Med] I'm assuming the following PCP deployment mode fro lw4ov6:
* The server assigns an external IPv4 address and a port set.
* The CPE will use the external port set for its NAT operations, including port forwarding purposes/
* The use of a PCP proxy is optional. 
* port forwarding can be dynamically instructed using UPnP IGD or PCP
* PCP requests issued from internal hosts are handled by the CPE itself if the CPE embeds a PCP server.

 I mean, the CPE
>could want to use PCP to control an plain IPv6 firewall for example.
[Med] Which firewall? Why you need it? 

 Do
>implicitly be IPv4 internal? 
[Med] I'm assuming, PCP is needed for lw4o6 to retrieve the port set and IPv4 address. No additional port control feature is needed.

That seems like a dangerous assumption to
>me...
[Med] Why?

---

From: Qiong <[email-masked]>
Date: Thu, 6 Jun 2013 17:07:13 +0800

Hi Med,

Thanks for your comments! See my reply inline.

> >> currently supported by various vendors.
[Qiong] DS-Lite would also have the same problem when deploying
anycast-based load balancing. I strongly suggest that DS-Lite should also
include this tunnel mode especially for this scenario.

> [Med] This is deployment-specific.

[Qiong] Yes. I agree anycast-based load balancing is a deployment choice.
But if you use this tunnel mode, it can also be deployed in unicast
scenario. So I recommend this tunnel mode in lw4over6. Is there some
problem when we apply tunnel mode in particular ?

> The hash computation can be updated to rely on IP-based information, no
> port numbers would be needed.
>
[Qiong] That will cost a lot, especially when lwAFTR is deployed in more a
centralized way that a lot of routers along the path all need to be
updated.

> [Med] Load-balancing can be achieved in various manners. Another scheme
> would be to avoid the use of anycast-based LB but dispatch CPE to the
> enabled lwAFTR by returning unicast addresses.
>
[Qiong] Agree. But in this deployment model, you will need another system
to compute which CPE will be assigned to which lwAFTR dynamically. Anycast
solution do not need to introduce this functionality.

> [Med] Unlike DS-Lite case for which THIRD_PARTY is needed to successfully
> do NAT in the AFTR, the lw4o6 only requires the IPv6@ of the lwB4 and not
> the internal IPv4 address. This another reason to adopt the plain IPv6
> mode. The binding table will associate an IPv6@ with {IPv4@, Port Set}.
>
[Qiong] I do not quite understand why this is the reason for plain IPv6
mode. Even in the tunnel mode, the binding table can also associate the
{IPv6@, IPv4@, Port set}. The IPv4 address inside the tunnel is the
well-known address and do not need to be kept in the mapping table.

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Jun 2013 11:41:56 +0200

Le 2013-06-06 11:07, Qiong a écrit :
>     The hash computation can be updated to rely on IP-based information,
>     no port numbers would be needed.
>
> [Qiong] That will cost a lot, especially when lwAFTR is deployed in more
> a centralized way that a lot of routers along the path all need to be
> updated.

I think this is a core issue that needs discussion.

Qiong, are you referring to ECMP?

Simon

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 6 Jun 2013 21:27:13 +0800

Hi Simon,

> Qiong, are you referring to ECMP?
[Qiong] Right, exactly. Currently, our routers from different vendors even with different versions may implement ECMP differently.

Best wishes

Qiong

---

From: <[email-masked]>
Date: Fri, 7 Jun 2013 14:39:25 +0200

Please see inline.

>De : [email-masked] [mailto:[email-masked]]
>Envoyé : jeudi 6 juin 2013 15:27
>À : Simon Perreault
>Cc : BOUCADAIR Mohamed OLNC/OLN; [email-masked]
[Med] .. but isn't L3-based ECMP LB needed for lw4over6 to work in your case?

>[Qiong] Right, exactly. Currently, our routers from different vendors even
>with different versions may implement ECMP differently.
[Med] Can you please point out an industrial product which supports L4-based ECMP LB and not L3-based one?