Re: [pcp] Comments on draft-ietf-pcp-dhcp-03

On 8/3/12 10:53 AM, "Dave Thaler" <dthaler@microsoft.com> wrote:

>> -----Original Message-----
>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
>> Reinaldo Penno (repenno)
>> Sent: Friday, August 03, 2012 10:45 AM
>> To: pcp@ietf.org
>> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03
>> 
>> After reviewing draft-ietf-pcp-dhcp-03 I believe there are some things I
>> believe we need to tie up.
>
>I agree.
>
>> When a PCP Client contacts PCP Servers in parallel, say, IPx1, IPy1 and
>> IPz1 as mentioned in draft and all respond then:
>> 
>> 1 - What happens to the state in y1 and z1 if PCP Client chooses x1 to
>> communicate? Probably let it age out or delete mappings.
>
>What do you mean by "chooses x1"?

That's what we find in section 6.2

>if we're talking about MAP (for a
>listening application) do you mean when x, y, and y
>are all NATs rather than FWs, and the client app can only deal with one
>external IP address?

The draft says as soon as one PCP Server responds successfully it sticks
to it. So, I'm assuming other PCP Server are not contacted further and
mappings will time out or need to be deleted.

As a side effect why would an app get 3 external IP:ports for the same
purpose and consume three times the state. It seems to me a side effect of
the wording more than something the app really needs.

>
>If they're firewalls (so the external IP address/port isn't different), or
>if the client app can deal with multiple external IP/ports, then I don't
>think
>it would choose one.

What's the use case for three? Anyway, this exchange is telling in light of

"Once the PCP Client has successfully
   received a response from a PCP Server on that interface, it sends
   subsequent PCP requests to that same server until that PCP Server
becomes non-responsive,"

> 
>> 2 - If there is a failure on x1 and PCP Client decides to communicate
>>with y1,
>> there might be some 'leftover' mappings for internal IP:port (see 1).
>> PCP Client will need to delete or reuse existing state in y1. Important
>>to
>> notice that there is no way to guarantee that PCP Server will allocate
>>same
>> external IP:ports.
>> 
>> 3 - I guess it is assumed that if PCP Server is co-located with NAT, if
>>x1 fails,
>> traffic (PCP and data) will be diverted to y1.
>
>Unclear which model you're referring to (different external IP:port or
>same external IP:port), can you clarify your question?

The app needs one external IP:port to announce on the external world
through, say, DynDDNS client. Why it would need three _different_? If it
needs them, fine, not sure about use case. But if it gets 3 as a
collateral effect of the bootstrap procedure there is no way to guarantee
they will be the same.

> 
>> 4 - Related (2). The draft says that when a PCP Server is unreachable
>>(say, y1)
>> PCP Client will continue to try to communicate even though other PCP
>>Server
>> are available.  The only way to 'communicate' is sending a request,
>>which
>> might create state. So, when y1 is back up. y1 might allocate a
>>different
>> external IP:port than other server.
>> 
>> Thanks,
>> 
>> Reinaldo
>> 
>> 
>> 
>> 
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>
>