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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, August 07, 2012 6:26 PM
> To: Tirumaleswar Reddy (tireddy); [e-mail]
> Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03
> 
> 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.

Hi Med -

The text looks good. If you can highlight at least one use case of multi-homing you have in mind that would be great (An example in the Appendix would also work)

--Tiru.

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