Re: [pcp] What's the final conclusion?答复: [Technical Errata Reported] RFC6887 (3887)

[Dan Wing <[e-mail]>]

On Feb 12, 2014, at 10:14 PM, "Zhangzhan (Channy)" <[e-mail]> wrote:

> This draft is proposed in 2011, but has expired, no refresh or replacement?

That's right.

> The PEER mode include remote address maybe can be selected correct zone.
> 
> The MAP mode only through the filter option to identify, if contains more than one filter in one PCP message, and these filters maybe belong to different zones. 
> And an address pool may contain a number of different segments address blocks, the filter maybe not be able to identify zones.
> 
> The ZONEID option should be a good solution, but the client to get the zones information is a very difficult thing, because zones in CGN is hidden for a client and no business relations. Zones maybe be changed, how to keep the synchronization is a problem.

That problem needs to be solved anyway, no matter if it's called ZONEID or called something else.

-d


> 
> -----邮件原件-----
> 发件人: Dan Wing [mailto:[e-mail]] 
> 发送时间: 2014年2月13日 10:23
> 收件人: Zhangzhan (Channy)
> 抄送: Ted Lemon; PCP Working Group; Stuart Cheshire; [e-mail] Boucadair; Reinaldo Penno; [e-mail]; Brian Haberman; Dave Thaler
> 主题: Re: What's the final conclusion?答复: [Technical Errata Reported] RFC6887 (3887)
> 
> 
> On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) <[e-mail]> wrote:
> 
>> Maybe you misunderstand me.
>> There is only one router for NAT and PCP.
>> If the NAT gateway device (such as CGN) is PCP Server and has two or more out interfaces to internet were doing different nat conversion in the ISP. 
>> Maybe using NAT address pool A, B, C... And the routing entries to internet on NAT gateway is equivalent default route. In this case, the out interface is uncertain, fully in accordance with the equivalent route selection.
>> If no PCP, service traffic can be selected out interface according to the destination address and do different NAT conversion.
>> But the PCP message is in before the normal service traffic. And PCP MAP mode message does not include the destination address, the NAT gateway device how to choose the out interfaces and the different NAT address pools? 
>> Based on the current PCP protocol, I think that can't be solved. Or what I understand something wrong?
> 
> With such a network topology, you are correct that the current MAP opcode doesn't work.  We need something different.  Would http://tools.ietf.org/html/draft-penno-pcp-zones be a viable solution?
> 
> -d
> 
> 
>> 
>> -----邮件原件-----
>> 发件人: Dan Wing [mailto:[e-mail]] 
>> 发送时间: 2014年2月13日 9:02
>> 收件人: Zhangzhan (Channy)
>> 抄送: Ted Lemon; PCP Working Group; Stuart Cheshire; [e-mail] Boucadair; Reinaldo Penno; [e-mail]; Brian Haberman; Dave Thaler
>> 主题: Re: What's the final conclusion?答复: [Technical Errata Reported] RFC6887 (3887)
>> 
>> 
>> On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" <[e-mail]> wrote:
>> 
>>> "Indeed, it has been discussed."
>>> 
>>> What's the final conclusion to the discussion? 
>>> 
>>> How PCP applies in the Dual-Egress NAT scene?
>>> 
>>> Could you please share it? 
>> 
>> I removed the RFC Editor from the thread.
>> 
>> PCP client needs to communicate to both of the NATs independently.  Which the same host (the PCP client) needs to know how to do anyway to send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to different networks, the host must have routing entries.  The PCP client can use those same routing entries to know there are two routers on the network, and send PCP messages to those two routers separately.
>> 
>> -d
>> 
>> 
>>> 
>>> -----邮件原件-----
>>> 发件人: Ted Lemon [mailto:[e-mail]] 
>>> 发送时间: 2014年2月13日 0:13
>>> 收件人: Dan Wing
>>> 抄送: RFC Errata System; Zhangzhan (Channy); Stuart Cheshire; [e-mail] Boucadair; Reinaldo Penno; [e-mail]; Brian Haberman; Dave Thaler; PCP Working Group
>>> 主题: Re: [Technical Errata Reported] RFC6887 (3887)
>>> 
>>> On Feb 12, 2014, at 10:15 AM, Dan Wing <[e-mail]> wrote:
>>>> It seems appropriate to discuss this question on the PCP mailing list, [e-mail].
>>> 
>>> Indeed, it has been discussed.   This isn't really an appropriate topic for an erratum.
>>> 
>> 
>