Subject: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 2 Jan 2013 23:29:41 +0000

Hello,

First of all, Happy new Year!

Based on the discussions at IETF Atlanta Meeting we would like to start
call of adoption on a few drafts, with the first one below.

This email starts a 2-week consensus call on adopting

     Title           : Learn NAT64 PREFIX64s using PCP
     Author(s)       : M. Boucadair
     Filename        : draft-boucadair-pcp-nat64-prefix64-option-02.txt
     URL             :
http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.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,

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 2 Jan 2013 23:34:35 +0000

Hello,

     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,

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 Jan 2013 17:39:03 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reinaldo Penno (repenno)
> Sent: Wednesday, January 02, 2013 3:35 PM
> To: [email-masked]
> Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09
> 
> Hello,
> 

The Applicability section, title, and section 2 need to be clarified 
if PCP-NATCOORD works with PRR, works with CGN (as defined by 
draft-ietf-behave-lsn-requirements), or only works with 
draft-cui-softwire-b4-translated-ds-lite.  Some of the Applicability section
is 
actually in section 2, where section 2 says:

   ... This mechanism can be applied for lightweight 4over6
   [I-D.cui-softwire-b4-translated-ds-lite] in port-set allocation
   process.  It can also be applied to stateless PCP-controlled device,
   in which the Internal address, External address and Port set is
   determined algorithmically.

Yet, section 6 says "Normally, the PCP server for MAP_PORT_SET will 
not run NAT" which conflicts with the document's own title ("Using
PCP To Coordinate Between the CGN and Home Gateway").

Nit: Figure 2 shows a 24 bit Reserved field, but the description
says it is 16 bits.  Also, Figure 2 has a cut/paste mistake
with Suggested Port Set Index (should be Assigned Port Set Index).

What is the status of draft-cui-softwire-b4-translated-ds-lite in
SOFTWIRE?

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: <[email-masked]>
Date: Thu, 3 Jan 2013 10:31:27 +0100

Hello WG,

I support the adoption of the draft as a pcp WG document. The proposed approach is useful to address the typical use cases mentioned in section 2.

Cheers,

Christian. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Reinaldo Penno (repenno)
Envoyé : jeudi 3 janvier 2013 00:30
À : [email-masked]
Objet : [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option

Hello,

Based on the discussions at IETF Atlanta Meeting we would like to start call of adoption on a few drafts, with the first one below.

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,

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alain Durand <[email-masked]>
Date: Thu, 3 Jan 2013 16:39:54 +0000

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...

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.

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 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.

Alain.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 4 Jan 2013 03:10:28 +0000

I also support this draft.

Regards,
Tiru.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 03, 2013 3:01 PM
> To: Reinaldo Penno (repenno); [email-masked]
> Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-
> option
> 
> Hello WG,
> 
> I support the adoption of the draft as a pcp WG document. The proposed
> approach is useful to address the typical use cases mentioned in section 2.
> 
> Cheers,
> 
> Christian.
> 
> Based on the discussions at IETF Atlanta Meeting we would like to start call
> of adoption on a few drafts, with the first one below.
> 
> 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,
> 
> 
> ______________________________________________________________________________
> ___________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> As emails may be altered, France Telecom - Orange is not liable for messages
> that have been modified, changed or falsified.
> Thank you.
>

---

From: Qiong <[email-masked]>
Date: Fri, 4 Jan 2013 17:55:17 +0800

Dear Dan,

Thanks for your comments. Please see inline ~~

On Thu, Jan 3, 2013 at 9:39 AM, Dan Wing <[email-masked]> wrote:

> [Qiong] Thanks for your suggestion. We will clarify it more clearly.
PCP_NATCOORD can not only work with
draft-cui-softwire-b4-translated-ds-lite, but can also work with PRR
(either using internal IPv4 address, or IPv6 address). In the current
draft, "the PCP server for MAP_PORT_SET will not run NAT" because the home
gateway will run NAT instead of PCP server, but it would be easy to modify
the draft to address the use cases which Reinaldo has pointed out in
http://www.ietf.org/mail-archive/web/pcp/current/msg02664.html. The WG can
decide which applicabilities should go in it when we agree that we should
start work on this port-set Opcode.
For the title and content in section 1 and 2, we will take reconsider it
once the applicability of MAP_PORT_SET has been determined by the WG.

> with Suggested Port Set Index (should be Assigned Port Set Index).
[Qiong] Thanks ! We will fix it.

> What is the status of draft-cui-softwire-b4-translated-ds-lite in
[Qiong] As far as I know, the concensus from the Atlanta meeting is that
draft-cui-softwire-b4-translated-ds-lite would be moved forward after the
softwire WG has a unified CPE draft covering both lightweight 4over6 and
MAP.

Hope it clarifies. Thanks !

Best wishes
Qiong

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

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

---

From: bingxuere <[email-masked]>
Date: Fri, 4 Jan 2013 21:52:37 +0800

Hi Alain,

Please see my comments inline below...

>     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.
>     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.
>    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.
>    is vastly over engineered.
The same with the above one.

Best wishes
Qiong

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Jan 2013 18:09:33 -0800

> From: Qiong [mailto:[email-masked]]
> Sent: Friday, January 04, 2013 1:55 AM
> To: Dan Wing
> Cc: Reinaldo Penno (repenno); [email-masked]
> Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09
> 
> Dear Dan,
> 
> 
> PCP_NATCOORD can not only work with draft-cui-softwire-b4-translated-ds-
> lite, but can also work with PRR (either using internal IPv4 address, or
> IPv6 address).

Can it work with a CGN?

> In the current draft, "the PCP server for MAP_PORT_SET
> will not run NAT" because the home gateway will run NAT instead of PCP
> server, but it would be easy to modify the draft to address the use
> cases which Reinaldo has pointed out in http://www.ietf.org/mail-
> archive/web/pcp/current/msg02664.html. The WG can decide which
> applicabilities should go in it when we agree that we should start work
> on this port-set Opcode.

With the current document text, I cannot understand what sort of 
deployments where NATCOORD can or cannot be used.  Until I understand
that, I can't decide if this document is a good idea or a bad idea.

> draft-cui-softwire-b4-translated-ds-lite would be moved forward after
> the softwire WG has a unified CPE draft covering both lightweight 4over6
> and MAP.

-d

> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sat, 5 Jan 2013 07:33:41 +0000

+1

> [email-masked]
> Sent: Thursday, January 03, 2013 5:31 PM
> Subject: Re: [pcp] WG Call for Adoption:
> draft-boucadair-pcp-nat64-prefix64-option
> 
> Hello WG,
> 
> Based on the discussions at IETF Atlanta Meeting we would like to start call of
> adoption on a few drafts, with the first one below.
> 
> adoption (and with reasoning why) in the mailing list. The call for adoption ends
> 16th January 2013.
> 
> 
> Thanks,
> 
> 
> ________________________________________________________________
> _________________________________________________________
>

---

From: Qiong <[email-masked]>
Date: Sat, 5 Jan 2013 16:33:06 +0800

Dear Dan,

Let me explain the deployment senario of NATCOORD here.

The major functionality of NATCOORD is to get the External Port-Set and
External public address for the PCP client. It is applied to the senario
where NAT is offloaded to the home gateway and the PCP-controlled device
does not run NAT(or port-mapping). The home gateway will restrict the
source port into the external port-set, and therefore the PCP-controlled
device does not need to do port-mapping anymore. Currently, there are
several candidate solutions can work with it, including lightweight 4over6,
PRR, and SLNAT44.

NATCOORD does not work with ordinary CGN because there is no need for the
home gateway to get a range of ports if it does not do port restriction.

We will clarify it in the document. Thanks a lot for your consideration !

Best wishes
Qiong

Open source code:

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sun, 6 Jan 2013 01:49:31 +0000

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. 

> bingxuere
> Sent: Friday, January 04, 2013 9:53 PM
> To: Alain Durand
> Cc: [email-masked]
> 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.
> >
> 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.
> >
> >     external IP addresses. Also, when ports are running low, connections
> may be delayed until a new port set is acquired.
> 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.
> >

---

From: Chongfeng Xie <[email-masked]>
Date: Sun, 6 Jan 2013 16:41:11 +0800

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) <[email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>>
> Date: Sun, Jan 6, 2013 at 9:49 AM
> To: "[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>" <
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>
>
>
> 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.
>
> > From: [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>] On Behalf Of
> > bingxuere
> > Cc: [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> > On 2013-1-4, at 上午12:39, Alain Durand <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
> 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.
> > >     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.
> > > 3) When asking for multiple of those port-sets, one may end-up with
> port sets
> > on different
> > >    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
> > > On Jan 2, 2013, at 6:34 PM, Reinaldo Penno (repenno) <
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>
> > wrote:
> > >
> > >> Hello,
> > >>
> http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt
> > >>
> > > [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> > [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Jan 2013 10:44:41 +0100

Dan,

Just trying to provide some more clarification...

> Can it work with a CGN?

Depends what you mean by CGN.

In the current draft version (-09), MAP_PORT_SET assumes that the NAT 
never changes port numbers. The NAT MAY change addresses.

It is possible to remove that assumption. We are planning to do that 
after the call for adoption. Then MAP_PORT_SET will be exactly like MAP, 
except that it works with port *sets* (obviously).

> that, I can't decide if this document is a good idea or a bad idea.

Hopefully the above explanation of the protocol will be sufficient for 
you to figure out its applicability. :)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Jan 2013 10:57:13 +0100

Salut Alain,

>       This would remove the complexity of port set indexes, max port set, etc...

One reason for MAP_PORT_SET is scalability.

- On the PCP client: you don't want to deal with e.g. 2048 MAP requests, 
then 2048 refreshes every X hours, etc.

- On the NAT: it allows allocating one single "set" entry, which may 
very well occupy less state memory than 2048 individual map entries.

Another reason is to get a contiguous chunk. There is no guarantee that 
multiple MAP requests will be able to obtain a contiguous chunk of port 
numbers. Some applications may find this property necessary (e.g. SIP 
clients).

> 2) There are already several DHCP (v4 and v6) options being defined to address this very problem,

No.

The DHCP options solve the very specific problem of provisioning a port 
set to a subscriber, in e.g. the LW4o6 use case.

MAP_PORT_SET is different. The best way to see it is as an extension to 
MAP: it allows to map port sets with PCP instead of single port numbers. 
It is applicable to LW4o6, but also in other use cases: applications 
that need chunks of continuous ports, Reinaldo's firewall use case, etc.

>       external IP addresses.

The MAP opcode has the same concern, and the same answer applies. Let us 
know if you think it should be made clearer in the text.

> Also, when ports are running low, connections may be delayed until a new port set is acquired.

This is up to the PCP client to figure out. The same concern applies to 
the MAP opcode.

Simon

---

From: Alain Durand <[email-masked]>
Date: Mon, 7 Jan 2013 15:55:49 +0000

On Jan 7, 2013, at 1:57 AM, Simon Perreault <[email-masked]>
 wrote:

> The DHCP options solve the very specific problem of provisioning a port set to a subscriber, in e.g. the LW4o6 use case.
> 
> MAP_PORT_SET is different. The best way to see it is as an extension to MAP: it allows to map port sets with PCP instead of single port numbers. It is applicable to LW4o6, but also in other use cases: applications that need chunks of continuous ports, Reinaldo's firewall use case, etc.

I think this is the crux of the issue. The draft needs to articulate exactly what the use case is and why other existing technologies are not sufficient. IMHO, simply saying we do not have a DHCP server in the target deployment does not cut it. You will need to introduce new software anyway (the PCP server) in your architecture, so the only difference between PCP & DHCP is the format of the bits on the wire.

> The MAP opcode has the same concern, and the same answer applies. Let us know if you think it should be made clearer in the text.

Yes.

> This is up to the PCP client to figure out. The same concern applies to the MAP opcode.

Not sure. with MAP opcode, the logic is that it is the user application that requests the port, in doing so, it knows that it may have to wait a little.
With the option described in the draft, the logic is that the CPE makes the request for an additional set of ports, unbeknown to the application...

Alain.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Jan 2013 17:13:51 +0100

> With the option described in the draft, the logic is that the CPE makes the request for an additional set of ports, unbeknown to the application...

There is no such difference. A MAP_PORT_SET request may be made either 
by an individual application or by the operating system, just like a MAP 
request.

Simon

---

From: Alain Durand <[email-masked]>
Date: Mon, 7 Jan 2013 16:19:08 +0000

On Jan 7, 2013, at 8:13 AM, Simon Perreault <[email-masked]> wrote:

> There is no such difference. A MAP_PORT_SET request may be made either by an individual application or by the operating system, just like a MAP request.

In theory, yes you are correct. In practice, it depends on the domain of application. If it is for lw4over6 (or similar), then the scenario I describe is the prevalent case.

Alain.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Jan 2013 17:23:44 +0100

> In theory, yes you are correct. In practice, it depends on the domain of application. If it is for lw4over6 (or similar), then the scenario I describe is the prevalent case.

Absolutely right. And I'd like to emphasize that we envision multiple 
usages for the MAP_PORT_SET opcode, one of which is indeed LW4o6.

Does this need to be clarified in the text?

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Jan 2013 08:54:17 -0800

> Simon Perreault
> Sent: Monday, January 07, 2013 1:45 AM
> To: [email-masked]

Previously, I cited draft-ietf-behave-lsn-requirements, as that is
perhaps the best citation the industry has for "what is a CGN".

> never changes port numbers. The NAT MAY change addresses.

Can that be made clearer in the document, *please*.

> except that it works with port *sets* (obviously).

Oh, so with that change, NATCOORD could work with CGN.

> you to figure out its applicability. :)

Another question:  what is the relationship between draft-tsou-pcp-natcoord
and draft-sun-dhc-port-set-option and draft-wu-dhc-port-set-option?  I 
saw there was a request to adopt draft-sun-dhc-port-set-option in DHC,
and lots of discussion.

I have not seen a discussion of using DHCP versus PCP for this
functionality, which concluded that PCP was the better choice.  Did 
that discussion occur?  If so, can we get a pointer to that 
discussion?

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Jan 2013 08:56:51 -0800

> Sent: Monday, January 07, 2013 1:57 AM
> To: [email-masked]
> multiple PCP requests.

By SIP, do you mean RTP?  If so, it seems draft-boucadair-pcp-rtp-rtcp 
provides that functionality.  draft-tsou-pcp-natcoord could, too, if
the size of the port-set is two ports, I guess?  Which should a client
or a server use?

-d

> port sets on different

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Jan 2013 18:04:30 +0100

> the size of the port-set is two ports, I guess?  Which should a client

Right, but I was thinking about a slightly different use case than 
draft-boucadair: some applications just like to get ownership of a chunk 
of ports when they start. This is mostly an implementation artifact, not 
really a protocol constraint. I had SIP apps in mind, but I guess the 
same could be said of BitTorrent apps or other apps that eat ports.

Simon

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Jan 2013 12:15:03 -0500

>>>>> "Simon" == Simon Perreault <[email-masked]> writes:

    Simon> Right, but I was thinking about a slightly different use case
    Simon> than draft-boucadair: some applications just like to get
    Simon> ownership of a chunk of ports when they start. This is mostly
    Simon> an implementation artifact, not really a protocol
    Simon> constraint. I had SIP apps in mind, but I guess the same
    Simon> could be said of BitTorrent apps or other apps that eat
    Simon> ports.

Let me give a concrete example.
A SIP PBX starts.
It wants to get a number of ports to use for media termination; probably
one or two for however many calls it might handle concurrently.
That's on over-estimate because of course ports can be reused if the
endpoints don't overlap.
The PBX doesn't want to generate PCP requests during call setup if it
has another option, so reserving a chunk of ports up front would be
valuable.

--Sam

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 7 Jan 2013 15:30:16 -0500

support. it brings a feature that is valuable in some deployments and use cases. Marc.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 07 Jan 2013 21:36:54 +0000

I also support it. In despite of the still open issues I think it can be
of interest for certain cases.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Tom Taylor <[email-masked]>
Date: Mon, 07 Jan 2013 18:29:43 -0500

Support.

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Tue, 8 Jan 2013 03:47:45 +0000

Support +1 although there are some issues being discussed now in the Mailing list 
but I think it is useful for some use case.

BR
Yu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Tuesday, January 08, 2013 7:30 AM
To: [email-masked]
Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09

Support.

---

From: Qiong <[email-masked]>
Date: Wed, 9 Jan 2013 21:26:43 +0800

Dear Dan,

> that discussion occur?  If so, can we get a pointer to that
[Qiong] For the relationship between draft-tsou-pcp-natcoord,
draft-sun-dhc-port-set-option and draft-wu-dhc-port-set-option,
draft-tsou-pcp-natcoord is a port-set extension for pcp-base and
draft-sun-dhc-port-set-option(updated version of
draft-wu-dhc-port-set-option ) is a port-set extension on dhcpv4. Both
draft-tsou-pcp-natcoord and draft-sun-dhc-port-set-option can work with
lightweight 4over6, but draft-tsou-pcp-natcoord is not only designed for
lw4over6 use case. It can also be used for other cases like Reinaldo's
firewall, SLNAT44, application-based port-set reservation, etc.

For lw4over6 use case, we do have a discussion of using DHCP or PCP among
lw4over6 co-authors (no much discussion in the mailing-list). But it's
truely hard to say which one is better. Different operators will have
different situations. For example, for operators with existing DHCP server
and is not planning to deploy CGN, they may prefer dhcp solution; while for
operators with no existing DHCP server and will deploy CGN in the early
stage, they may prefer pcp solution. So it is really a deployment choice
for them.

Hope it clarifies.

Best wishes
Qiong

  first

Open source code:

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Jan 2013 07:48:43 -0800

> Sent: Wednesday, January 09, 2013 5:27 AM
> To: Dan Wing
> Cc: Simon Perreault; [email-masked]
> [Qiong] For the relationship between draft-tsou-pcp-natcoord, draft-sun-
> dhc-port-set-option and draft-wu-dhc-port-set-option, draft-tsou-pcp-
> natcoord is a port-set extension for pcp-base and draft-sun-dhc-port-
> set-option(updated version of draft-wu-dhc-port-set-option ) is a port-
> set extension on dhcpv4. Both draft-tsou-pcp-natcoord and draft-sun-dhc-
> port-set-option can work with lightweight 4over6, but draft-tsou-pcp-
> natcoord is not only designed for lw4over6 use case. It can also be used
> for other cases like Reinaldo's firewall, SLNAT44, application-based
> port-set reservation, etc.
> 
> 
> For lw4over6 use case, we do have a discussion of using DHCP or PCP
> among lw4over6 co-authors (no much discussion in the mailing-list). But
> it's truely hard to say which one is better. Different operators will
> have different situations. For example, for operators with existing DHCP
> server and is not planning to deploy CGN, they may prefer dhcp solution;
> while for operators with no existing DHCP server and will deploy CGN in
> the early stage, they may prefer pcp solution. So it is really a
> deployment choice for them.

We all know the industry is best served with a single standard, 
rather than multiple standards (both a PCP mechanism and a DHCP 
mechanism).  Too many choices is actually harmful, rather than
helpful.

I would really like to see the need for both PCP and DHCP before either
working group adopts a mechanism.  If we don't do that now, the
same question is likely to arise when during IETF last call or during
IESG review.

-d

---

From: Simon Perreault <[email-masked]>
Date: Wed, 09 Jan 2013 16:52:40 +0100

> same question is likely to arise when during IETF last call or during

Even if the DHCP mechanism would get chosen for LW4o6, I would argue 
that MAP_PORT_SET still has merit on its own, for the non-LW4o6 purposes 
we have described.

So I don't see the LW4o6 aspect as a killer, at all. It's just one 
potential customer.

Simon

---

From: Qi Sun <[email-masked]>
Date: Sun, 13 Jan 2013 23:19:35 +0800

Dear all,

I'm in favor of this draft. I think it should move forward.

Best Regards!

Qi Sun
Tsinghua Univ.

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Mon, 14 Jan 2013 19:13:15 +0200

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

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Jan 2013 18:30:11 +0000

On Jan 9, 2013, at 10:52 AM, Simon Perreault <[email-masked]> wrote:

> Even if the DHCP mechanism would get chosen for LW4o6, I would argue that MAP_PORT_SET still has merit on its own, for the non-LW4o6 purposes we have described.

I would like to see those merits being fully articulated before the wg adopt this draft.

    - Alain.

---

From: Qiong <[email-masked]>
Date: Tue, 15 Jan 2013 10:22:55 +0800

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 <
[email-masked]> wrote:

> Also, as i already have informed the pcp authors about the base spec, i
> was hoping to see a solution for non-continuous

Open source code:

---

From: Qiong <[email-masked]>
Date: Tue, 15 Jan 2013 13:09:36 +0800

I am in favor of this draft. Support to move forward.

Best wishes
Qiong

On Sat, Jan 5, 2013 at 3:33 PM, Zhangdacheng (Dacheng) <
[email-masked]> wrote:

> > Objet : [pcp] WG Call for Adoption:
> call of
> against
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce
> > message par erreur, veuillez le signaler
> > If you have received this email in error, please notify the sender and
> delete this
> > message and its attachments.

Open source code:

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Wed, 16 Jan 2013 07:43:09 +0000

Support.

Best Regards,
Cathy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qiong
Sent: Tuesday, January 15, 2013 1:10 PM
To: Zhangdacheng (Dacheng)
Cc: [email-masked]
Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option

Best wishes
Qiong

On Sat, Jan 5, 2013 at 3:33 PM, Zhangdacheng (Dacheng) <[email-masked]<mailto:[email-masked]>> wrote:
+1

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> [email-masked]<mailto:[email-masked]>
> To: Reinaldo Penno (repenno); [email-masked]<mailto:[email-masked]>
> De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de
> Reinaldo Penno (repenno)
> À : [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
pcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pcp

Open source code:

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sun, 20 Jan 2013 14:27:53 +0200

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 <[email-masked]>
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

Any plans for that?

Thanks,

Tassos

pcp mailing list

[email-masked]

--

Qiong Sun

Open source code:

---

From: Qiong <[email-masked]>
Date: Mon, 21 Jan 2013 22:23:39 +0800

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 <
[email-masked]> wrote:

> 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.
>
> 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
> 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
> 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
>
>
>
>  Yes, we can easily modify to support it. Could you explain a little more
> on the intention of this use case ?
>
>  Best wishes
>  Qiong
>
>
>> I support this draft, but i would like to see more cases covered (and

Open source code:

---

From: Dave Thaler <[email-masked]>
Date: Sun, 27 Jan 2013 01:59:30 +0000

I have read the draft and all of the emails from others regarding it.

From the list discussion, there does appear to be rough consensus for
having the ability for an application to get a range of ports in one
PCP message exchange rather than requiring a separate exchange per port.

That said, I do not think that draft-tsou-pcp-natcoord-09 is ready to be
adopted as a WG draft.

First, it seems clear that there are a number of use cases for which a range
of ports is useful (as Simon, Sam, and Ian among others have
pointed out).  However, draft-tsou-pcp-natcoord is too heavily focused
on one particular scenario, both in terms of motivation text and in terms
of the packet format proposed).  And it seems it's still unclear
(as Alain and Dan have stated) whether PCP is the right solution for
that scenario.  For the more generic use cases, I personally believe the
specific packet format proposed is not a good match as noted below.

Specific feedback:

1) Personally I find the use of port set prefix/suffix/index/mask
   confusing and unnecessarily complex for the more general scenarios
   of "please give me N ports".  For a general mechanism I would instead
   expect a simple "number of ports desired/allocated".  That simple
   mechanism would also be more flexible.  For example, it could allow
   sizes that are not a power of two, thus preventing wasted ports in
   some scenarios.

2) I believe a new Opcode is not the right solution for requesting a
   range of ports.  Instead, I think it would be more appropriate to have
   an Option, usable with the existing MAP Opcode, that had the number
   of ports desired/allocated starting at the external port number already
   present in the MAP Opcode.  This allows the existing logic and constraints
   regarding MAP to be applied without duplicating it in another spec
   or in another set of code.

3) The motivation text does not talk about other use cases, and indeed
   I'd prefer that a document we adopt be generic in supporting port
   range scenarios and not focus on a use case on which there isn't clear
   consensus whether PCP is the right solution.

4) The title and filename are not particularly helpful in conveying what
   the document is about.  I'd expect a document whose title and filename
   are about a port range extension.

If the above items were done in a doc, it's possible the result might have
little or no text from the current document, and I wonder whether it'd
be faster to start from scratch.  Hence I don't think it's ready to be
adopted as a WG draft yet.

-Dave

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sun, 27 Jan 2013 21:33:44 +0200

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,

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 <[email-masked]>
wrote:

Hi Qiong,

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.

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

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 <[email-masked]>
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

Any plans for that?

Thanks,

Tassos

Reinaldo Penno (repenno) wrote on

>      Title     : Using PCP To
Coordinate Between the CGN and Home
Gateway

pcp mailing list

[email-masked]

--

Qiong Sun

Open source code:

--

Qiong Sun

Open source code: