Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt

<ian.farrer@telekom.de> Tue, 29 October 2013 13:44 UTC

Return-Path: <ian.farrer@telekom.de>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473BE11E823D for <dhcwg@ietfa.amsl.com>; Tue, 29 Oct 2013 06:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTL6CszuwYMx for <dhcwg@ietfa.amsl.com>; Tue, 29 Oct 2013 06:44:02 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7151211E815F for <dhcwg@ietf.org>; Tue, 29 Oct 2013 06:44:01 -0700 (PDT)
Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 29 Oct 2013 14:43:59 +0100
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 29 Oct 2013 14:43:59 +0100
From: <ian.farrer@telekom.de>
To: <otroan@employees.org>
Date: Tue, 29 Oct 2013 14:43:53 +0100
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
Thread-Index: Ac7UrOwipq5L1w9BRw2fnEJuQyKLNQ==
Message-ID: <CE952CF3.8EDA1%ian.farrer@telekom.de>
In-Reply-To: <73774E7F-38E3-4F41-822C-093444CA99B1@employees.org>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.8.130913
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 29 Oct 2013 13:44:07 -0000

Hi Ole,


Thanks for the review. I¹ve updated the draft based on your comments. And
some more answers in line.

Cheers,
Ian


>
>yes, I think a clarification in the introduction would help.
>stateful DHCPv4 doesn't apply to DS-lite, and it is difficult to see how
>it applies to MAP.
>which link-layer did you have in mind for this?
>is this work meant to also provide stateful DHCPv4 for MAP tunnels?

[ian] It¹s not meant to be limited to any particular softwire or other v4
type. If someone was to have a reason for using stateful DHCPv4 for MAP at
some point in the future, then this IPv4 configuration

>
>e.g. a configured RFC2473 tunnel or Public 4over6, could work.
>
>when it comes to provisioning of a shared IPv4 address, DHCPv4 doesn't
>really do that.
>I don't see that described in this document?

[ian] The draft¹s concerned with how IPv4 configuration is transported,
not what the specific v4 configuration is.

>I think we need to evaluate if there should be a completely new option
>for IPv4 address and port set, or
>a the classic IPv4 address option combined with a new port set option.

[ian] There¹s a couple of drafts out there that do this at the moment:
draft-sun-dhc-port-set-option & draft-farrer-dhc-shared-address-lease. I
think that it¹s better to handle the format and other considerations
around option formats and shared address leasing separate from the
transport question covered in this draft.

>
>>> Section 2:
>>> Drop requirement 6, I can't see how you can evaluate that.
>> 
>> [ian] You can evaluate it on the following basis: If the requirements
>>that are described in this document are not your requirements as an
>>operator, then you shouldn't be forced to use whatever the conclusion of
>>this document is. In practical terms, I see this as 'if MAP DHCP meets
>>your requirements, you don't need to bring in DHCPv4 over Foo or
>>whatever else'.
>
>I didn't quite understand the implications of that.

[ian] During the discussion in Atlanta that led up to writing this
document, an opinion voiced by several operators was: If I can provision
everything I need using simple, static DHCPv6 (I.e. Option map), why
should I have the additional overhead of a DHCPv4 providing additional
DHCPv4 options and dynamic leasing which is unnecessary to me?

The requirement is there to evaluate whether a solution allows you to do
that.

>
>>> 8 is empty
>>> 
>> [ian] Will fix.
>> 
>>> I suggest you add a new requirement:
>>> x. Fate sharing. The provisioning of IPv4 addressing and other
>>>configuration information should be logically tied
>>>     to the data-link layer that is uses to provide IPv4 connectivity.
>> 
>> [ian] This one's going to be more of a problem, as it pretty much
>>directly conflicts with requirement 7, in that the two contradict each
>>other. You can only implement data link fate sharing if you've got a hub
>>and spoke architecture to locate the hub in (so that if it's not
>>available, then IPv4 provisioning also fails)
>
>which link-layer fails that?
>I'm dubious about requirement 7 overall. and e.g. DHCPv4 over DHCPv6 is
>restricted to there being a DHCPv6 transport available.

[ian] There¹s a slot for this draft in Vancouver. Can we discuss it there
as this has a direct effect on the outcome?

>
>> In the case of a pure mesh network, with no hub and spoke, how could
>>you have fate sharing for the data-link layer? The proposed requirement
>>pre-supposes a specific underlying architecture.
>
>is this the equivalent to the dentist's office case? can you give an
>example of other data link-layers where IPv4 can be provisioned on a NBMA
>link, without a router?

[ian] Not familiar with the Dentist office in this particular context.

The obvious example would be a single Ethernet segment with a DHCP server
attached, but I¹m not sure how that¹s relevant to this discussion.

>
>> Can we put this one to the workgroup to ask if this should be included
>>as a new req, as it' has not been previously discussed?
>> 
>>> 
>>> Section 3:
>>> DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.
>> 
>> [ian] Why is it a 'no' for req 4? Section 8 of the DHCPv4 over DHCPv6
>>draft:
>> 
>> Additionally, the DHCPv6 relay agent MAY allow the configuration of
>>   dedicated DHCPv4 over DHCPv6 specific destination addresses,
>>   differing from the addresses of the DHCPv6 only server(s).  To
>>   implement this function, the relay checks the received DHCPv6 message
>>   type and forwards according to the following logic:
>> 
>>   1.  If the message type is BOOTREQUESTV6, then the DHCPv6 request is
>>       relayed to the configured DHCPv4 aware 4o6 Server's address(es).
>> 
>>   2.  For any other DHCPv6 message type, forward according to section
>>       20 of [RFC3315].
>
>DHCPv4 over DHCPv6 requires support for transporting DHCPv4 messages in
>DHCPv6 servers and clients.

[ian] Or, you could add a minimal DHCPv6 encapsulation to a DHCPv4 server.

>what do you mean by "independent DHCPv4 and DHCPv6 servers" then?

[ian] if you wanted to deploy DHCPv6 servers and DHCPv4overDHCPv6 servers
as separate instances, you can. Given how complex the DHCPv6 server logic
can become, there¹s some good reasons no to overload the DHCPv6 server
with DHCPv4 functions as well.

>could you clarify the requirements?
>now they do read like they have been reverse engineered.

[ian] Extended the definition with an explanation.

>
>> For the fate sharing req, as stated above.
>> 
>>> 
>>> In the evaluation in section 3.x I suggest dropping the use of
>>>"complex" and "simple".
>>> That appears very subjective.
>>> 
>> [ian] OK
>> 
>>> 3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases.
>> 
>> [ian] How so? If you have a 'wrapper' type of approach (where DHCPv4 is
>>being put into IPv6 or DHCPv6), then the DHCPv4 over xv6 client function
>>can be agnostic to what the physical interface is beyond 'it must
>>support multicast or unicast'. If the DHCPv4oSW mechanism is not linked
>>just to softwires and is essentially a 'vanilla' DHCPv4 client, then it
>>must have awareness of the link layer capabilities of the link on which
>>it is running and potentially adapt it's behaviour accordingly, such as
>>per-client l4 port-restrictions.
>
>I read this bullet to be about the interface to be _provisioned_.
>regardless of how that information reaches the client, the client must be
>aware of the link-layer restrictions. and that I believe apply to all
>mechanisms, regardless.
>
>> 
>>>         bullet 4. please expand.
>> 
>> [ian] This was from a question I asked on the ML some time ago, but
>>wasn't answered. Does MAP-T support broadcasts through the translator
>>function?
>
>I don't see why it wouldn't.

[ian] OK, removed the con.

>
>>>         bullet 5. change to "Restricted to a broadcast capable
>>>link-layer."
>> 
>> [ian] Is the hub-and-spoke restriction incorrect? As mentioned above, I
>>don't see how this approach can work in a mesh environment. The
>>'broadcast capable' restriction is not correct as if a h&s softwire can
>>support broadcast, then a ptp mesh softwire can as well. You could
>>broadcast DHCPDISCOVERs to peers in a mesh group, but it's not going to
>>get you any response.
>
>MAP in mesh mode, still has a point to point tunnel to the BR.
>we have not described MAP in a 'pure' mesh mode, i.e. without a BR.

[ian] This document isn¹t meant to be limited to MAP mesh. E.g. RFC5565.

>
>>> 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from each
>>>other since it 
>>>         it is DHCPv6 that provides transport for DHCPv4. and support
>>>for the new BOOTP messages
>>>         are required in DHCPv6.
>> 
>> [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed
>>separate from the DHCPv6 only server. What about changing to read?:
>> 
>> 'DHCPv4 and DHCPv6 based provisioning infrastructure can be seperated'
>
>as long as there is a DHCPv4 message capable DHCPv6 server.

[ian] Sure. But if you didn¹t have a DHCPv4 capable server, then you
wouldn¹t have sent the DHCPv4pDHCPv6 client the option to tell it to
attempt DHCPv4oDHCPv6 configuration.

>