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

[<[e-mail]>]

Dear all,

Thanks for those who already answered to this message. I'm re-sending to seek for more opinions.

Thanks in advance.

Cheers,
Med


>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la part de
>[e-mail]
>Envoyé : mardi 13 août 2013 08:26
>À : [e-mail]
>Objet : [pcp] draft-ietf-pcp-dhcp: multiple pcp servers
>
>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