Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

<mohamed.boucadair@orange.com> Wed, 19 March 2014 09:27 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150371A069A for <dhcwg@ietfa.amsl.com>; Wed, 19 Mar 2014 02:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRt-ush6upUK for <dhcwg@ietfa.amsl.com>; Wed, 19 Mar 2014 02:26:59 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 80FB21A06FD for <dhcwg@ietf.org>; Wed, 19 Mar 2014 02:26:59 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 903A02DC22E; Wed, 19 Mar 2014 10:26:50 +0100 (CET)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6B3984C056; Wed, 19 Mar 2014 10:26:50 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 19 Mar 2014 10:26:50 +0100
From: <mohamed.boucadair@orange.com>
To: "Bernie Volz (volz)" <volz@cisco.com>, Ted Lemon <mellon@fugue.com>, DHC WG <dhcwg@ietf.org>
Date: Wed, 19 Mar 2014 10:26:48 +0100
Thread-Topic: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.
Thread-Index: Ac9DVVmcW8HOUkX3TDyhLigNCnfz1g==
Message-ID: <94C682931C08B048B7A8645303FDC9F36F51A2DB17@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.18.134216
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/fNA2Lv0YLqBaA4zkDvmMY48j2Lo
Subject: Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 09:27:04 -0000

Hi Bernie,

Thanks for the comments.

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Bernie Volz (volz) [mailto:volz@cisco.com]
>Envoyé : mardi 18 mars 2014 23:12
>À : Ted Lemon; DHC WG
>Cc : BOUCADAIR Mohamed IMT/OLN; Reinaldo Penno (repenno); Dan Wing (dwing)
>Objet : RE: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section
>5.
>
>Hi:
>
>If we are to allow this (multiple instances of the same option), I think it
>would be prudent to clarify that RFC 3396 does NOT apply for this option
>for DHCPv4.
I think this is the first option we have that cannot use this?
[Med] This is not new, RFC3925 allows to send multiple instances of the same option.

>(I'm not sure 3396 was even prepared for this situation, but I could be
>wrong.)
[Med] RFC3396 says the following: 

"   This specification also applies in any case where a DHCP protocol
   agent has received a DHCP packet that contains more than one instance
   of an option of a given type.  In this case, the agent MUST
   concatenate these separate instances of the same option in the way
   that we specify here."

I guess this text covers the case of this draft. No?

If my interpretation is correct, then the following text can be added to the draft:

  " The OPTION_PCP_SERVER DHCPv4 option is a concatenation-requiring
   option.  As such, the mechanism specified in [RFC3396] MUST be used
   if the OPTION_PCP_SERVER option exceeds the maximum DHCPv4 option size
   of 255 octets."

>
>This will place special requirements on both servers and clients (servers
>not to split, clients not to combine).
>
>Note that http://www.arkko.com/tools/allstats/citations-rfc3396.html is
>useful to see which options are defined to be concatenation-requiring
>options.
>
>
>For DHCPv6, this is less of an issue but certainly again an unusual (the
>first?) case - excepting IA_*, IAADDR/IAPREFIX, and vendor options.
>
>(I would hope the PCP WG has a sufficiently strong motivation for needing
>these multiple PCP server instances.)
[Med] The context is the following: multiple PCP servers can be configured to a PCP client; each of these server can have one or multiple IP addresses. The indication whether the set of addresses belong to the same pcp server or distinct one is import for the PCP server selection procedure.

>
>For DHCPv6, it is also a bit odd to have:
>
>   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.
>
>(BTW: Note the typo here - DHPCv6?)
[Med] It is DHCPv6 indeed. The motivation text is provided in the draft:

     " 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])."

>
>- Bernie
>
>-----Original Message-----
>From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
>Sent: Tuesday, March 18, 2014 12:06 PM
>To: DHC WG
>Subject: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.
>
>I've requested an IETF Last call on this document, so now's the time for
>any last tweaks.   I mention section 5 because the way it uses distinct
>options of the same type seems innovative and possibly not ideal.
>
>https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/
>
>Thanks!
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg