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

[<[e-mail]>]

Dear all,

I added this text to the draft:

   The discovery procedure may result in a PCP Client instantiating
   multiple mappings maintained by distinct PCP Servers.  The decision to
   use all these mappings or delete some of them is deployment-specific.
   Only the client can decide whether all the mappings are needed or
   only a subset of them.

I don't think we can say more in this draft. This is really a deployment-specific issue. 

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la 
>part de Dave Thaler
>Envoyé : vendredi 3 août 2012 22:30
>À : Reinaldo Penno (repenno); [e-mail]
>Objet : Re: [pcp] Comments on draft-ietf-pcp-dhcp-03
>
>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 
>
>
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp
>