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

I agree the work can bring some benefit (e.g., simplify the operations) in certain scenarios. So, support the adoption of this work if authors would like to keep improving it. 

> -----Original Message-----
> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> bingxuere
> Sent: Friday, January 04, 2013 9:53 PM
> To: Alain Durand
> Cc: pcp@ietf.org
> Subject: 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
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp