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

["Bernie Volz (volz)" <[e-mail]>]

I would not like to go that route for v4. I think you should use a 3369 friendly encoding.

- Bernie (from iPad)

> On Mar 20, 2014, at 2:50 AM, "[e-mail]" <[e-mail]> wrote:
> 
> Hi Bernie,
> 
> This seems like the format described in a previous version of the draft: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-06#section-4.1 (s/name/address(es)).  
> 
> Is it problematic if we declare the design in the draft as being not compatible with RFC3369? RFC3396 indicates that specification requiring 3396 must explicit it in their specs. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Bernie Volz (volz) [mailto:[e-mail]]
>> Envoyé : mercredi 19 mars 2014 14:35
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : DHC WG; Ted Lemon
>> Objet : RE: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section
>> 5.
>> 
>> To support 3396, you will likely have to encode the DHCPv4 PCP option as:
>> 
>>    Option Code
>>    Length of option
>>    Length of PCP server 1
>>    IPv4 address(es) based on length of PCP server 1
>>    <Repeat the following as often as needed>
>>    Optional length of PCP server n
>>         IPv4 address(es) based on PCP server n
>> 
>> So, the 2 PCP servers mentioned below would be encoded as (each line is a
>> byte unless otherwise indicated):
>> 
>>    <PCP Option Code>
>>    <Length = 1 + 4 + 4 + 1 + 4>
>>    8 (Length of PCP server 1)
>>    4 bytes address - 10.1.1.1
>>    4 bytes address - 10.1.1.2
>>    4 (Length of PCP server 2)
>>    4 bytes address - 10.2.2.2
>> 
>> This can be split and there is only ONE instance of the option, but there
>> can be multiple sub-instances.
>> 
>> This would be compatible with what RFC 3925 does.
>> 
>> - Bernie
>> 
>> -----Original Message-----
>> From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
>> Sent: Wednesday, March 19, 2014 7:39 AM
>> To: [e-mail]
>> Cc: DHC WG; Ted Lemon
>> Subject: Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly
>> section 5.
>> 
>> No, RFC 3925 vendor options were carefully designed to comply with 3396.
>> They can be split and concentenated.
>> 
>> For your draft you want the multiple instances NOT to be concatenated at
>> least as I understand it. This is so you can tell there are 2 PCP servers,
>> not just one with multiple addresses, if two PCP options are present.
>> 
>> For example if client receives two options:
>> PCP option with 10.1.1.1 and 10.1.1.2
>> PCP option with 10.2.2.2
>> 
>> You want that treated as two separate servers, not as a concatenated option
>> of:
>> PCP option with 10.1.1.1, 10.1.1.2, 10.2.2.2 Which is what would happen if
>> 3396 was applied by a client.
>> 
>> - Bernie (from iPad)
>> 
>>>> On Mar 19, 2014, at 5:26 AM, "[e-mail]"
>>> <[e-mail]> wrote:
>>> 
>>> Hi Bernie,
>>> 
>>> Thanks for the comments.
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Bernie Volz (volz) [mailto:[e-mail]] 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:[e-mail]] 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg