Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09

[Simon Perreault <[e-mail]>]

Salut Alain,

Le 2013-01-03 17:39, Alain Durand a écrit :
> 1) This functionality can be achieved very simply on a CPE by sending multiple PCP requests.
>       This would remove the complexity of port set indexes, max port set, etc...

One reason for MAP_PORT_SET is scalability.

- On the PCP client: you don't want to deal with e.g. 2048 MAP requests, 
then 2048 refreshes every X hours, etc.

- On the NAT: it allows allocating one single "set" entry, which may 
very well occupy less state memory than 2048 individual map entries.


Another reason is to get a contiguous chunk. There is no guarantee that 
multiple MAP requests will be able to obtain a contiguous chunk of port 
numbers. Some applications may find this property necessary (e.g. SIP 
clients).

> 2) There are already several DHCP (v4 and v6) options being defined to address this very problem,

No.

The DHCP options solve the very specific problem of provisioning a port 
set to a subscriber, in e.g. the LW4o6 use case.

MAP_PORT_SET is different. The best way to see it is as an extension to 
MAP: it allows to map port sets with PCP instead of single port numbers. 
It is applicable to LW4o6, but also in other use cases: applications 
that need chunks of continuous ports, Reinaldo's firewall use case, etc.

> 3) When asking for multiple of those port-sets, one may end-up with port sets on different
>       external IP addresses.

The MAP opcode has the same concern, and the same answer applies. Let us 
know if you think it should be made clearer in the text.

> Also, when ports are running low, connections may be delayed until a new port set is acquired.

This is up to the PCP client to figure out. The same concern applies to 
the MAP opcode.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca