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

[Dan Wing <[e-mail]>]

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

> This solution is feasible?
> 
> We define a new result code, such as MULTIPLE_ZONES, and define a new Opcode, such as GET_ZONE.
> If the PCP server have more than one ZONE, reply a MULTIPLE_ZONES result code message when receiving any PCP requests.
> The client receives the result code, must send a GET_ZONE Opcode request message.
> The PCP server must replay a message which contains the list of all ZONE ID information.
> Then the client get the ZONE ID information, sends request messages (PEER or MAP) which include ZONEID option. If there are N zones, client must send N request messages.
> Finally The PCP server can be selected the different address pools according to the ZONEID information and create multiple different mapping tables.
> If the zone information is changed in PCP server, mapping tables must be deleted and create new mapping table when receiving renewing messages from clients.

Seems like a good first cut, but I don't like breaking backwards compatibility with existing PCP clients.  Backwards compatibility is broken in that second step (the step starting with "If the PCP server have more than one ZONE ...").  Better would be if the PCP client tries to do zone discovery when it sends its first MAP (such as an PCP option), as that doesn't change state machine much.   Here is what I am thinking (view with fixed-width font):

PCP Client    	      	           PCP	Server	
----------    	      	           ----------
    |                                   |
    |---MAP w/LEARN_ZONES option------->|
    |                                   |
    |                   (one mapping is created)
    |                                   |
    |<--mapped to zone=1, total zones=3-|
    |                                   |
    |--GET_ZONE 1 details-------------->|
    |<--zone 1 details------------------|
    |                                   |
    |--GET_ZONE 2 details-------------->|
    |<--zone 2 details------------------|
    |                                   |
    |--GET_ZONE 3 details-------------->|
    |<--zone 3 details------------------|
    |                                   |
    |--MAP, ZONE=2--------------------->|
    |<-ok-------------------------------|
    |                                   |
    |--MAP, ZONE=3--------------------->|
    |<-ok-------------------------------|
    |                                   |


-d


> 
> -----邮件原件-----
> 发件人: Dan Wing [mailto:[e-mail]] 
> 发送时间: 2014年2月13日 14:22
> 收件人: 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 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.
>>>> 
>>> 
>> 
>