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

Hi Alain,

Please see my comments inline below...

On 2013-1-4, at 上午12:39, Alain Durand <adurand@juniper.net> wrote:

> I do not support the adoption of this document as wg item, for essentially three reasons.
> 
> 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 port set PCP request is obviously better than multiple individual PCP requests. It can not only save the bandwidth of massive PCP requests, reduce the mapping entries in PCP server, and greatly reduce the burden of PCP server dealing with individual requests in a short time,etc. Considering one subscriber will get a port set with 2048 ports, this simple port set Opcode can save 2047 requests for one time. I don't see why we do not use it.
> 
> 2) There are already several DHCP (v4 and v6) options being defined to address this very problem,
>     and my understanding is that there is an attempt at converging those in DHC & Softwires.
>     If a PCP option absolutely must be defined as well (which honestly I doubt), I would hope
>     it would be defined exactly the same way as the yet-to-be-defined final DHCP option.
1) Using PCP is quite helpful in cases: a. An operator with no DHCP server or not enable to upgrade to support this new feature b. An operator planning to migrate the dslite AFTR to behave as a port range router. Just as we can have both RFC6334 for dhcp option and RFC6519 for radius option, it is totally a deployment choice. Besides, this port set Opcode can also be applied to other use cases as Reinaldo has pointed out. 
2) Adopting a WG item does not mean the work has finished, rather, we just provide a starting point for which the WG will decide which way to go. This is the most efficient way for the sake of this work, and we all see how PCP-base has improved from -01 to -29. In the same way, the specific format of this port set Opcode can be modified to reflect the consensus from the WG.
> 
> 3) When asking for multiple of those port-sets, one may end-up with port sets on different
>     external IP addresses. Also, when ports are running low, connections may be delayed until a new port set is acquired.
>    There are problems associated with these scenarii and they should be analyzed.
In section 3.3, we have clearly say that the same external address should be assigned to one subscriber in multiple port set requests. And we also recommend that the server assign the maximum allowed port set in a single request. But I don't think the protocol itself should restrict this capability. It is still a deployment choice.
> 
>    In the end, there is a trade-off between flexibility and complexity. The question
>    is, in REAL operation, is the flexibility of having multiple port sets needed?
>    In CGN deployments I'm familiar with, ISPs assign a fixed amount of ports per user that should be
>    enough for everybody and don't change it. If this is not good enough for a particular user,
>    the simplest thing to do is to take him/her out of the CGN pool and assign him/her a full IPv4 address.
>    In other words, I think that this notion of  handing out multiple port sets with pseudo-random ports
>    is vastly over engineered.
The same with the above one.

Best wishes
Qiong
> 
> Alain.
> 
> 
> 
> 
> On Jan 2, 2013, at 6:34 PM, Reinaldo Penno (repenno) <repenno@cisco.com> wrote:
> 
>> Hello,
>> 
>> This email starts a 2-week consensus call on adopting
>> 
>>    Title     : Using PCP To Coordinate Between the CGN and Home Gateway
>>    Author(s) : Q. Sun et al
>>    Filename  : draft-tsou-pcp-natcoord-09.txt
>>    URL       : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt
>> 
>> Please read the current revision and state you opinion either for or
>> against adoption (and with reasoning why) in the mailing list.
>> 
>> The call for adoption ends 16th January 2013.
>> 
>> Thanks,
>> 
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp