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

From: <[email-masked]>
Date: Tue, 13 Aug 2013 08:26:20 +0200

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) ([email-masked]); Dan Wing ([email-masked])
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:[email-masked]]
>Envoyé : mercredi 7 août 2013 19:56
>À : Ted Lemon; BOUCADAIR Mohamed OLNC/OLN
>Cc : Reinaldo Penno (repenno) ([email-masked]); Dan Wing
>([email-masked])
>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:[email-masked]]
>> Sent: Wednesday, August 7, 2013 8:26 AM
>> To: [email-masked]
>> Cc: Dave Thaler; Reinaldo Penno (repenno) ([email-masked]); Dan Wing
>> ([email-masked])
>> Subject: Re: PCP DHCP I-D: your feedback is needed
>>
>> On Aug 7, 2013, at 3:00 AM, [email-masked] 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.
>>
>
>

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 13 Aug 2013 08:04:53 +0000

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, "[email-masked]"
<[email-masked]> wrote:

>Dear all,
>
>The design of the DHCP PCP option
>(http://tools.ietf.org/html/draft-ietf-pcp-dhcp-08) assumes:
>(4) It is up to an administrative entity to return one or multiple pcp
>servers. No restriction is made by design.
>
>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
>
>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:
>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.
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 15:12:06 +0200

Ted,

Some comments are listed below:

* The design in -08 does not differ from previous versions: multiple instances of the option were described in previous versions. What has been changed is only the encoding: use an IP address instead of names.

* The design does not extend RFC3315 which does not exclude an option to appear several times.

* As you can notice, no normative language is used in the server guideline section. This is to accommodate existing implementations. 

* There are already existing DHCP option specification documents which allow to return multiple options (e.g., RFC 5908, RFC 6731, RFC 6784, etc.)

* What is important IMHO is to make sure the client is expecting to receive multiple options. 

Cheers,
Med

>De : Ted Lemon [mailto:[email-masked]]
>Envoyé : mardi 13 août 2013 14:48
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : pcp@
>Objet : Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers
>
>On Aug 13, 2013, at 2:26 AM, [email-masked] wrote:
>BTW, Med presents this as if it is the consensus of the working group, long
>since decided, but I would like the working group to consider the
>practicality of the proposal and not just the shopping list of features
>that Med has presented here.   I do not doubt that the working group
>previously agreed to this shopping list, but I am a bit skeptical that all
>involved actually understood what the proposal would do in terms of its
>impact on the DHCP protocol.
>
>The current DHCP PCP option draft that Med has published differs from
>previous drafts in that it uses DHCP option structure to convey semantics.
>Like the previous proposal, this new proposal extends the DHCP protocol and
>winds up updating RFC3315 to add new functionality that will require code
>changes on all DHCP servers and clients.
>
>The reason this is the case is that the DHCP server indicates to the DHCP
>client how many PCP servers there are by sending a PCP server option per
>PCP server.   And it indicates that a PCP server has multiple IP addresses
>by sending multiple IP addresses in a single PCP option.   So DHCP servers
>have to be able to do both of these things: send multiple PCP options, and
>send multiple IP addresses per option.   This is not functionality present
>in current DHCP servers.
>
>If the working group wishes to extend the DHCP protocol in this way, this
>would be out of scope for the PCP working group-the work would have to be
>done in the DHC working group.   The DHC working group is likely to make
>just such an extension, which would apply to all DHCP options, in order to
>support multiple provisioning domains, but that is future work.
>
>What would be most expedient for _this_ working group would be to define a
>simple option that delivers one or more IP addresses of PCP servers.   This
>is something that could be finished soon, and used soon.   I would argue
>that it is up to the client what it wants to do with those IP addresses; if
>the addresses refer to multiple PCP servers, that is something that can be
>discovered using the PCP protocol, and need not be conveyed in a DHCP
>option.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Aug 2013 10:34:41 -0400

> * The design in -08 does not differ from previous versions: multiple instances of the option were described in previous versions. What has been changed is only the encoding: use an IP address inste…

Perhaps that's so.   I've been so focused on the really big problems with previous versions of the draft that I didn't notice this one, if it was in fact present.

> * The design does not extend RFC3315 which does not exclude an option to appear several times.

Yes, it does.   This is why work of this sort needs to be done in the DHC working group, not in the PCP working group: that is where the expertise on DHCP is.   You think that because it is possible to represent this data in a DHCP packet, that no changes are required in the protocol.   But in fact in order to implement what you have documented in the current draft, all DHCP servers and DHCP clients will have to be modified.   That is what it means to update the DHCP protocol.   Show me where in RFC 3315 there is text describing how DHCP servers can indicate multiple servers by sending multiple options, and can indicate multiple IP addresses on the same server by including them in the same option.

> * As you can notice, no normative language is used in the server guideline section. This is to accommodate existing implementations. 

An extension is required to get the behavior this document requires.   That is all that is needed for the document to be a protocol extension.   If you fail to specify the details of how that extension works, that doesn't mean you haven't extended the protocol: it just means you've done an incomplete job of it.

> * There are already existing DHCP option specification documents which allow to return multiple options (e.g., RFC 5908, RFC 6731, RFC 6784, etc.)

Yes, that's true.   See above.

> * What is important IMHO is to make sure the client is expecting to receive multiple options. 

That's certainly the most important part of this protocol extension, yes.   To be clear, it isn't enough that the client be prepared to accept multiple options; clients can already do that.   What is needed is for the client to accept multiple options _and do the right thing_ with them.

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 17:05:42 +0200

Re-,

Please see inline.

Cheers,
Med

>Envoyé : mardi 13 août 2013 16:35
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [email-masked]
>Yes, it does.   This is why work of this sort needs to be done in the DHC
>working group, not in the PCP working group: that is where the expertise on
>DHCP is.

[Med] Fully agree. Apologies for not ccing dhcwg earlier (now cced). The initial message can be found here: http://www.ietf.org/mail-archive/web/pcp/current/msg03327.html 

   You think that because it is possible to represent this data in
>a DHCP packet, that no changes are required in the protocol.   But in fact
>in order to implement what you have documented in the current draft, all
>DHCP servers and DHCP clients will have to be modified.   That is what it
>means to update the DHCP protocol.   Show me where in RFC 3315 there is
>text describing how DHCP servers can indicate multiple servers by sending
>multiple options, and can indicate multiple IP addresses on the same server
>by including them in the same option.

[Med]  RFC3315 says the following:

"Unless otherwise noted, each option may appear only in the options
   area of a DHCP message and may appear only once.  If an option does
   appear multiple times, each instance is considered separate and the
   data areas of the options MUST NOT be concatenated or otherwise
   combined."

RFC 3315 does not need to describe what is conveyed inside each instance of the option and how that information is configured to the server. IMHO, this is the responsibility of the option specification documents. 

I agree there are some aspects which need to be discussed in a more generic dhcp document such as the name resolution behavior at the dhcp server side. What to do if both an IPv4 address and IPv6 addresses are returned, and so on. I'm referring to this text from the draft:

   The DHCP server may be configured with one or multiple FQDNs of the
   PCP server(s).  In such case, the DHCP server must resolve these
   FQDNs into one or a list of IP addresses from pre-configured DNS
   server(s).  If multiple FQDNs are configured to the DHCP server, the
   DHCP server must include multiple OPTION_PCP_SERVER instances; each
   of them carries one or a list of IP addresses that resulted from the
   FQDN resolution.  DHCPv4 servers supporting PCP server option must
   resolve any configured FQDN into an IPv4 address while DHCPv6 servers
   may resolve any configured FQDN into an IPv6 and/or IPv4 address.  If
   an IPv4 address is retrieved by the DHCPv6 server, the corresponding
   IPv4-mapped IPv6 address is included in the OPTION_PCP_SERVER DHPCv6
   option.  If both IPv4 and IPv6 addresses are retrieved by the DHCPv6
   server, these addresses are included in the same OPTION_PCP_SERVER
   DHPCv6 option (IPv4 addresses are represented as IPv4-mapped IPv6
   addresses).

      Discussion: The motivation for this design is to accommodate
      deployment cases where an IPv4 connectivity service is provided
      while only DHPCv6 is in use (e.g., an IPv4-only PCP server in a
      DS-Lite context [RFC6333]). 

If this discussion is included in [I-D.lemon-dhc-topo-conf], this would be great and will let me remove that text from this one.

>
>> * As you can notice, no normative language is used in the server
>guideline section. This is to accommodate existing implementations.
>
>An extension is required to get the behavior this document requires.   That
>is all that is needed for the document to be a protocol extension.   If you
>fail to specify the details of how that extension works, that doesn't mean
>you haven't extended the protocol: it just means you've done an incomplete
>job of it.

[Med] That section is only about configuration not about protocol extension. I see you call this protocol extension. 

>
>> * There are already existing DHCP option specification documents which
>allow to return multiple options (e.g., RFC 5908, RFC 6731, RFC 6784, etc.)
>
>That's certainly the most important part of this protocol extension, yes.
>To be clear, it isn't enough that the client be prepared to accept multiple
>options; clients can already do that.   What is needed is for the client to
>accept multiple options _and do the right thing_ with them.

[Med] Agree, this is why a normative reference to draft-ietf-pcp-server-selection is cited. The WG decided to remove that part from this draft and specify it in the generic pcp server selection I-D (which is not specific to dhcp).

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 14 Aug 2013 09:21:38 +0000

I agree with Med, the current design should be maintained. The other reasons would be:

In scenario http://tools.ietf.org/html/draft-ietf-pcp-server-selection-01#appendix-A.1 PCP client would want to send PCP request with FLOWDATA option to 
both rtr1 and rtr2, so that it can prioritize the source addresses (ICE host candidates) based on FLOWDATA response (if the requested flow characteristics can be met or not or partially met). This mechanism will help the client (ICE agent) to get the responses directly from rtr1 and rtr2 which will help to prioritize the ICE candidates and send offer/answer.

we are working on a draft on How PCP can be used to influence the host's ICE candidate selection algorithm and plan to use the current design which solves the problem for both multi-homing and MIF scenarios.

--Tiru.