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

[Alain Durand <[e-mail]>]

On Jan 7, 2013, at 1:57 AM, Simon Perreault <[e-mail]>
 wrote:

> 
>> 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.

I think this is the crux of the issue. The draft needs to articulate exactly what the use case is and why other existing technologies are not sufficient. IMHO, simply saying we do not have a DHCP server in the target deployment does not cut it. You will need to introduce new software anyway (the PCP server) in your architecture, so the only difference between PCP & DHCP is the format of the bits on the wire.

> 
>> 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.

Yes.

> 
>> 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.

Not sure. with MAP opcode, the logic is that it is the user application that requests the port, in doing so, it knows that it may have to wait a little.
With the option described in the draft, the logic is that the CPE makes the request for an additional set of ports, unbeknown to the application...

Alain.