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

[Qiong <[e-mail]>]

Dear Tassos,

Thanks for your explaination. I now understand your case.

I think the only difference is the port-set format. The current draft only
defines contiguous port-mask format. In order to support your case, we can
add an option to convey these individual non-contiguous ports in a single
request with PREFER_FAILURE. Then, the PCP server will only reply the
client when it can find an available external address to meet all his/her
requirements (follow the PREFER_FAILURE option). Is it ok for you ?

Best wishes
Qiong

On Sun, Jan 20, 2013 at 8:27 PM, Tassos Chatzithomaoglou <
[e-mail]> wrote:

>  Hi Qiong,
>
> I'm quoting my original email to the pcp authors.
> If you need more info, please don't hesitate to contact me.
>
> I've read the draft (26) twice during the last weeks (we'll hopefully try
> PCP soon in our network) and i think i'm missing the feature to include
> multiple ports in the same request/response (when talking about CPE as PCP
> client and a router/AFTR as PCP server). I've read draft-tsou-pcp-natcoord
> which came out due to a different motivation, but i don't think it fits in
> and i would certainly prefer to have it in the base spec. If i'm not wrong,
> the absence of this feature means that there is no way to have the PCP
> client instruct the PCP server to assign any external ip address, as long
> as ALL the specific port requirements of a single request are met.
>
> Take the following scenario for example:
>
> If a PCP client wants ports 80,443,8080 (the user has configured port
> forwarding for these ports in his/her CPE) and these are not available on
> its current external ip address, then by trying continuous one port
> requests the client might never get all three ports in the same ip address,
> while at the time of any single request there could be at least one
> external ip address with all these three ports available.
> i.e. as a solution an extra option should be given to change (causing a
> session "disconnect" if needed) to a new external ip address that can offer
> ALL three ports (such an option could be activated on the PCP client by the
> provider, probably as a new DHCP option while discovering the PCP server).
> If such an external ip address is not available, then the behavior of
> PREFER_FAILURE should be followed (if explicitly requested).
>
> Keeping that in mind, i couldn't also find any recommendations on whether
> the PCP server should try to service requests from PCP clients in a
> specific order that will allow as many PCP clients as possible to succeed
> in their port requirements. Is this somehow arranged by some other
> functionality/protocol/entity?
> If multiple ports could be assigned in the same request/response, then it
> would be easier for the PCP server to assign external addresses/ports after
> a mass reconnect of PCP clients.
> After all, i don't expect port forwarding rules to change often in CPEs
> after the initial configuration.
>
> Generally, i'm worried of having a lot of subscribers using external ip
> addresses that do not have the requested ports available after some time,
> while many other addresses can satisfy their port requirements. In such a
> case i would prefer to have the option (or give the option to subscriber)
> of "transferring" him/her from one ip to another, in order to satisfy all
> his/her requirements.
>
>
>
> Thanks,
> Tassos
>
>
>
> Qiong wrote on 15/1/2013 04:22:
>
> Dear Tassos,
>
>  Yes, we can easily modify to support it. Could you explain a little more
> on the intention of this use case ?
>
>  Best wishes
>  Qiong
>
>
> On Tue, Jan 15, 2013 at 1:13 AM, Tassos Chatzithomaoglou <
> [e-mail]> wrote:
>
>> I support this draft, but i would like to see more cases covered (and
>> some parts are not very clearly written).
>>
>> Also, as i already have informed the pcp authors about the base spec, i
>> was hoping to see a solution for non-continuous
>> port assignments in a single request.
>> Any plans for that?
>>
>> Thanks,
>> Tassos
>>
>> Reinaldo Penno (repenno) wrote on 03/01/2013 01:34:
>>  > 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]
>> > https://www.ietf.org/mailman/listinfo/pcp
>> >
>>
>> _______________________________________________
>> pcp mailing list
>> [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/ *
> ===============================================
>
>
>


-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================