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

[Chongfeng Xie <[e-mail]>]

i support the adoption of this document. Compared with the existing
pcp-base, I think pcp-natcood is more effective and efficient for port-set
allocation,
thanks

Chongfeng Xie

---------- Forwarded message ----------
> From: Zhangdacheng (Dacheng) <[e-mail] <javascript:_e({},
> 'cvml', '[e-mail]');>>
> Date: Sun, Jan 6, 2013 at 9:49 AM
> Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09
> To: "[e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>" <
> [e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>>
>
>
> 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: [e-mail] <javascript:_e({}, 'cvml',
> '[e-mail]');> [mailto:[e-mail] <javascript:_e({},
> 'cvml', '[e-mail]');>] On Behalf Of
> > bingxuere
> > Sent: Friday, January 04, 2013 9:53 PM
> > To: Alain Durand
> > Cc: [e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>
> > 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 <[e-mail]<javascript:_e({}, 'cvml', '[e-mail]');>>
> 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) <
> [e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>>
> > 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
> > > [e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>
> > > https://www.ietf.org/mailman/listinfo/pcp
> >
> > _______________________________________________
> > pcp mailing list
> > [e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>
> > https://www.ietf.org/mailman/listinfo/pcp
> _______________________________________________
> pcp mailing list
> [e-mail] <javascript:_e({}, 'cvml', '[e-mail]');>
> https://www.ietf.org/mailman/listinfo/pcp
>
>
>
> --
> ==============================================
> Qiong Sun
> China Telecom Beijing Research Institude
>
>
> Open source code:
> lightweight 4over6: *http://sourceforge.net/projects/laft6/*
> PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
> ===============================================
>
>