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

[Tassos Chatzithomaoglou <[e-mail]>]

Hi Qiong,

Your proposal seems ok (and agrees with mine), as long as this behavior can be disabled in order to use the default one.

--
Tassos

Qiong wrote on 21/01/2013 16:23:

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" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/pcp
>

_______________________________________________
pcp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcp" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/pcp

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


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/" target="_blank" rel="nofollow">http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/" target="_blank" rel="nofollow">http://sourceforge.net/projects/pcpportsetdemo/
===============================================

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


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/" target="_blank" rel="nofollow">http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/" target="_blank" rel="nofollow">http://sourceforge.net/projects/pcpportsetdemo/
===============================================