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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Ted Lemon [mailto:[e-mail]]
>Envoyé : mardi 13 août 2013 16:35
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [e-mail]
>Objet : Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers
>
>On Aug 13, 2013, at 9:11 AM, [e-mail] wrote:
>
>> * 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.

[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.)
>
>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.

[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).