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

[<[e-mail]>]

Dear Tiru,

I added this text to the draft to reflect your comment:

   Multiple Names may be configured to a PCP Client in some deployment
   contexts such as multi-homing.  It is out of scope of this document
   to enumerate all deployment scenarios which require multiple Names to
   be configured.

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la 
>part de Tirumaleswar Reddy (tireddy)
>Envoyé : mardi 7 août 2012 04:10
>À : Dave Thaler; Reinaldo Penno (repenno); [e-mail]
>Objet : Re: [pcp] Comments on draft-ietf-pcp-dhcp-03
>
>> A small number of examples might be nice, but I don't think 
>it can ever
>> be complete,
>> and so we shouldn't try to enumerate all possible cases.
>
>Yes, we need some examples.
>
>--Tiru.
>
>> -----Original Message-----
>> From: Dave Thaler [mailto:[e-mail]]
>> Sent: Tuesday, August 07, 2012 7:05 AM
>> To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno);
>> [e-mail]
>> Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03
>> 
>> > -----Original Message-----
>> > From: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>> > Sent: Sunday, August 5, 2012 2:46 PM
>> > To: Dave Thaler; Reinaldo Penno (repenno); [e-mail]
>> > Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03
>> >
>> > Hi -
>> >
>> > I think we need to clarify in the draft when multiple PCP server
>> names/IP
>> > addresses will be returned by the DHCP server, for example like
>> multi-homing
>> > case.
>> 
>> A small number of examples might be nice, but I don't think 
>it can ever
>> be complete,
>> and so we shouldn't try to enumerate all possible cases.
>> 
>> > Considering various other cases other than multi-homing
>> >
>> > [1]In High Availability mode of NAT/Firewall devices 
>(Active/Passive
>> Mode),
>> > PCP client still gets just one IP address.
>> >
>> > [2] For example in the draft http://tools.ietf.org/html/draft-rpcw-
>> pcp-pmipv6-
>> > serv-discovery-00 where selected traffic is offload at the local
>> access network.
>> > Mobile Node is provided only the PCP server address in the Local
>> Access
>> > Network and MAG decides if the PCP request will be handled by Home
>> network
>> > or Local Access Network.
>> >
>> > [3] In Enterprise use case there could be two to three different
>> possibilities
>> >
>> > a)All the traffic from the branches tunneled back to the 
>head office
>> where
>> > there is a NAT/Firewall device.
>> >
>> > b)Split Tunneling - In this case branch site itself would have
>> NAT/Firewall to
>> > handle traffic to Internet.
>> > How will the DHCP server be populated with the right 
>Firewall/NAT IP
>> > addresses in this case ?
>> >
>> > [4]
>> > Finally we will also need to solve the problem with just 
>IPv6 (NPTv6,
>> Firewall)
>> > where there is no DHCPv6 server.
>> > From RFC6106
>> > "RA-based DNS configuration is a useful alternative in 
>networks where
>> an IPv6
>> > host's address is auto-configured through IPv6 stateless address
>> auto-
>> > configuration and where there is either no DHCPv6 infrastructure at
>> all or
>> > some hosts do not have a DHCPv6 client"
>> 
>> I (with no hats) disagree that a no-DHCPv6 server case needs to be
>> solved by this WG.
>> 
>> -Dave
>> 
>> > --Tiru.
>> >
>> > > -----Original Message-----
>> > > From: Dave Thaler [mailto:[e-mail]]
>> > > Sent: Friday, August 03, 2012 2:30 PM
>> > > To: Reinaldo Penno (repenno); [e-mail]
>> > > Subject: 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
>