Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers

["Prashanth Patil (praspati)" <[e-mail]>]

I agree with what's been currently described in the draft today i.e if a
PCP Client receives multiple PCP servers, it should contact all of them
independently (not to be confused with a single PCP server reachable over
multiple IP addresses). The list should be treated as a list of active PCP
servers purposefully deployed and not a list of primary and backup servers.

If a deployment is designed to have a master PCP server that syncs to
other PCP servers, then the PCP client should only learn about that PCP
server and nothing else. There are some serious concerns about this
approach that need to be sorted out if we wish to support this ­ the
master PCP server will essentially be a PCP proxy with a lot of additional
capability.

-Prashanth


On 13/08/13 11:56 AM, "[e-mail]"
<[e-mail]> wrote:

>Dear all,
>
>The design of the DHCP PCP option
>(http://tools.ietf.org/html/draft-ietf-pcp-dhcp-08) assumes:
>(1) multiple pcp servers may be received from the same DHCP server.
>(2) one pcp server may be reachable with multiple IP addresses.
>(3) when multiple pcp servers are returned, the pcp client will need to
>contact all these servers.
>(4) It is up to an administrative entity to return one or multiple pcp
>servers. No restriction is made by design.
>
>FWIW, this design was in the draft since -02.
>
>Dave is echo'ing a comment which objects this design and advocates for
>restricting the design to return only one pcp server and it is up to the
>administrative entity to sync the state in all enabled PCP servers. IMO,
>this objection is not technically sound, at least for the following
>reasons:
>
>(1) The protocol cannot discover in one single request all external IP
>addresses and port numbers. Imagine the case where a NPTv6 and NAT64
>boxes are deployed. The PCP client has no means to learn with one single
>request to a single PCP server both the external IPv4 address (assigned
>by the NAT64 device) and the external IPv6 address assigned by the NPTv6
>box. The same issue is encountered when multiple NAT configured with
>distinct pool are in place.
>  
>(2) A host connected to a multi-homed domain, in which FW are located at
>the border router in front of each adjacent domain, will need to open
>pinholes in these FW if it want to receive incoming traffic from a remote
>peer. 
>
>(3) The protocol does not specify how state synchronization is to be
>achieved between several PCP servers. The task is even complex when these
>pcp servers are controlling functions of distinct types (e.g., NAT44, FW,
>NAT64, Port Range Router, etc.). Other issues are raised (see to the
>pcp-server-selection thread)
>
>(4) Mandating one and only one pcp server is to be returned is really
>deployment-specific. This assumption will induce a lot of complexity at
>the network side
>
>For those who are objecting the design as currently documented in -07, it
>is time to raise your concern (preferably with the technical arguments
>that motivate your point). If no technical argument is made, the current
>design will be maintained as it is.
>
>Cheers,
>Med
>
>-----Message d'origine-----
>De : BOUCADAIR Mohamed OLNC/OLN
>Envoyé : lundi 12 août 2013 07:56
>À : 'Dave Thaler'; Ted Lemon
>Cc : Reinaldo Penno (repenno) ([e-mail]); Dan Wing
>([e-mail])
>Objet : RE: PCP DHCP I-D: your feedback is needed
>
>Hi Dave,
>
>I disagree to put the constraint on the network deploying many PCP
>servers to coordinate state instantiating. This is a deployment specific
>assumption which is not trivial to honor.
>
>A domain may deploy various pcp server controlling functions which are
>not of the same nature, e.g., a domain may deploy:
>* one or multiple nat64 provisioned to IPv6-only hosts
>* one or multiple nptv6 provisioned to IPv6-only and dual stack hosts
>* one or multiple nat44 provisioned to IPv4-only and dual stack hosts
>* one or multiple IPv4 fw
>* one or multiple IPv6 fw
>* multiple flow-based access routers
>* etc.
>
>The design as currently document in the pcp server selection draft (and
>its dhcp instantiation) does not make any deployment assumption. As such:
>* an administrative entity can return one single IP address but instead
>it must ensure state are installed in other servers.
>* an administrative entity can return multiple servers; it is up to the
>client to contact these servers to install the state.
>
>This is much more better than constraining the design by non-valid
>deployment assumptions.
>
>I agree, this should be discussed in the list.
>
>Cheers,
>Med
>
>>-----Message d'origine-----
>>De : Dave Thaler [mailto:[e-mail]]
>>Envoyé : mercredi 7 août 2013 19:56
>>À : Ted Lemon; BOUCADAIR Mohamed OLNC/OLN
>>Cc : Reinaldo Penno (repenno) ([e-mail]); Dan Wing
>>([e-mail])
>>Objet : RE: PCP DHCP I-D: your feedback is needed
>>
>>I think this thread should move to the main WG mailing list, so Ted if
>>you
>>agree,
>>please forward/respond on this thread there.
>>
>>This is related to my comments on draft-ietf-pcp-server-selection-01.txt.
>>
>>If the app needs semantics of "contact each PCP server" then you need to
>>know
>>how to distinguish PCP servers.  Now more recently various members of the
>>WG (e.g. Stuart) have disputed the notion that an app needs to "contact
>>each PCP
>>server" and so we do not have consensus that this is required.   Stuart
>>proposed
>>that it's the PCP server's job to coordinate with any other servers
>>managed
>>by
>>the same entity (or to steal a term from MIF... within the same
>>provisioning domain).
>>No one has given a counter argument, and so I said in email we should
>>start
>>with that
>>assumption.
>>
>>You do need to distinguish provisioning domains (for reasons discussed in
>>MIF that
>>apply to PCP like they do to anything else).   So the only remaining
>>interesting case
>>I think is figure 2 in section A.2 of draft-ietf-pcp-server-selection-
>>01.txt where if
>>you have a local gateway with a DHCP server (e.g. a home gateway) that's
>>multi-homed
>>to two external provisioning domains each with their own PCP server(s),
>>what do you
>>get from DHCP?  I think the best answer here is to make the local gateway
>>be a
>>PCP proxy, and so DHCP just gives you its address.
>>
>>In such a solution, I believe there is no need to differentiate between
>>multiple
>>IPs of the same server vs multiple IPs of different servers.  That is,
>>you
>>communicate
>>with any one server IP, and you assume that it will take care of making
>>sure that
>>all servers with any of those IPs get the info.
>>
>>I believe this then removes any new concepts from DHCP and requires no
>>additional support in DHCP servers.
>>
>>-Dave
>>
>>> -----Original Message-----
>>> From: Ted Lemon [mailto:[e-mail]]
>>> Sent: Wednesday, August 7, 2013 8:26 AM
>>> To: [e-mail]
>>> Cc: Dave Thaler; Reinaldo Penno (repenno) ([e-mail]); Dan Wing
>>> ([e-mail])
>>> Subject: Re: PCP DHCP I-D: your feedback is needed
>>>
>>> On Aug 7, 2013, at 3:00 AM, [e-mail] wrote:
>>> > Ok, done.
>>>
>>> Thanks.
>>>
>>> Can you explain your motivation for adding new text differentiating
>>between
>>> multiple IP addresses that refer to the same PCP server, and multiple
>>>IP
>>> addresses that refer to different PCP servers?   Is this something the
>>working
>>> group asked to have added to the document?   I think this is a new
>>concept in
>>> the current document, and of course, it requires special support in the
>>DHCP
>>> server and DHCP client just for PCP.
>>>
>>> This is not the only issue with your current set of edits to the
>>document, but
>>> I'd just like to get clarity on this one issue before proceeding on to
>>the next.
>>>
>>
>>
>
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp