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

[Dave Thaler <[e-mail]>]

Responding on list for benefit of others, although we already
talked in person...

> -----Original Message-----
> From: Reinaldo Penno (repenno) [mailto:[e-mail]]
> Sent: Friday, August 03, 2012 11:18 AM
> To: Dave Thaler; [e-mail]
> Subject: Re: Comments on draft-ietf-pcp-dhcp-03
> 
> On 8/3/12 10:53 AM, "Dave Thaler" <[e-mail]> wrote:
> 
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> >> Reinaldo Penno (repenno)
> >> Sent: Friday, August 03, 2012 10:45 AM
> >> To: [e-mail]
> >> 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

Yes but the text is lacking, as this exchange shows.

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

Two reasons (cases):
a) there's different networks it's providing the same service on, e.g.
    via the Internet and via some other network.
b) for failover purposes.   For example, if it uses SRV records, it'd have
   3 SRV records.   If one NAT goes down, the other end will automatically
   use a different IP:port pair (which might be via a different ISP).   Otherwise
   the failover time is capped at the TTL of the SRV record, and we know
   DNS TTLs below around 30 seconds aren't respected by many DNS servers.
   So having multiple records provides sub-30-second failover.

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

Answered above.   Note I'm not saying three is appropriate in all cases.
Only that there is a use case, and the choice is up to the client,
which is the only entity that knows the use case.

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

Answered above.

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