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

[Dan Wing <[e-mail]>]

On Feb 13, 2014, at 5:56 PM, "Zhangzhan (Channy)" <[e-mail]> wrote:

> 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-------------------------------|
>    |                                   |
> 
> I think this solution has one problem.
> Based on RFC6887, we add a new LEARN_ZONES option, and client send this option message firstly to get zone number of PCP server. 
> It seems that pcp client know the server has more than one ZONEs in advance.

No, it doesn't.  LEARN_ZONE would be in the optional-to-process range, so the PCP client can safely send that option with any MAP request.  If the PCP server understands LEARN_ZONE, it includes LEARN_ZONE information in the response.  I show that the LEARN_ZONE information would merely indicate the number of zones supported.  If the PCP server does not understand LEARN_ZONE, the PCP server omits the LEARN_ZONE option from the response, but otherwise creates the requested MAP normally (that is, the PCP server behaves as if the optional-to-process LEARN_ZONE was not in the request at all).

This gives good backwards and forwards compatibility.


> But in actual network pcp client how to get this information? 
> I think that supplementing on the basis of the existing is a better way for protocol compatibility.
> 
> Refer to your idea chart, my idea chart is as follows:
> 
> PCP Client    	      	           PCP	Server	
> ----------    	      	           ----------
>    |                                   |
>    |---MAP/PEER request--------------->|
>    |                                   |
>    |                 (have more than one ZONEs)
>    |                                   |
>    |<-----MULTIPLE_ZONES resultcode----|
>    |                                   |
>    |--GET_ZONE Opcode----------------->|
>    |<--------------all zones detail----|
>    |                                   |
>    |--MAP/PEER zone 1----------------->|
>    |                                   |
>    |                       (mapping to zone 1)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>    |--MAP/PEER zone 2----------------->|
>    |                                   |
>    |                       (mapping to zone 2)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>    |--MAP/PEER zone 3----------------->|
>    |                                   |
>    |                       (mapping to zone 3)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
> 
> 
> Based on your idea, my idea to make the following change:
> 
> PCP Client    	      	           PCP	Server	
> ----------    	      	           ----------
>    |                                   |
>    |---MAP/PEER request--------------->|
>    |                                   |
>    |                 (have more than one ZONEs)
>    |                                   |
>    |<----MULTIPLE_ZONES resultcode
>          ZONES_NUM option(zones=3)-----|

So, that is an error message.    Existing PCP clients will be unable to create any sort of mapping.  That seems undesirable, as it forces PCP clients to understand how to handle zones, or else they cannot function.  If that is the desire, it is better to create an entirely new opcode instead of overloading MAP as I proposed.  I don't think such a failure is desirable.  Why force zone-unaware PCP clients to fail?

-d


>    |                                   |
>    |--GET_ZONE 1 details-------------->|
>    |<--zone 1 details------------------|
>    |                                   |
>    |--GET_ZONE 2 details-------------->|
>    |<--zone 2 details------------------|
>    |                                   |
>    |--GET_ZONE 3 details-------------->|
>    |<--zone 3 details------------------|
>    |                                   |
>    |--MAP/PEER zone 1----------------->|
>    |                                   |
>    |                       (mapping to zone 1)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>    |--MAP/PEER zone 2----------------->|
>    |                                   |
>    |                       (mapping to zone 2)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>    |--MAP/PEER zone 3----------------->|
>    |                                   |
>    |                       (mapping to zone 3)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
> 
> The coupling degree of this idea is smaller, or not?
> 
> 
> -----邮件原件-----
> 发件人: Dan Wing [mailto:[e-mail]] 
> 发送时间: 2014年2月14日 1:45
> 收件人: Zhangzhan (Channy)
> 抄送: Ted Lemon; PCP Working Group; Stuart Cheshire; [e-mail] Boucadair; Reinaldo Penno; [e-mail]; Brian Haberman; Dave Thaler
> 主题: Re: This solution is feasible?答复: What's the final conclusion?答复: [Technical Errata Reported] RFC6887 (3887)
> 
> 
> 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.
>>>>> 
>>>> 
>>> 
>> 
>