Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-opt-netboot-05

Thomas Huth <THUTH@de.ibm.com> Sat, 10 October 2009 14:15 UTC

Return-Path: <THUTH@de.ibm.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2923A6814 for <dhcwg@core3.amsl.com>; Sat, 10 Oct 2009 07:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ropIW2ALWJ-x for <dhcwg@core3.amsl.com>; Sat, 10 Oct 2009 07:15:30 -0700 (PDT)
Received: from mtagate5.de.ibm.com (mtagate5.de.ibm.com [195.212.17.165]) by core3.amsl.com (Postfix) with ESMTP id 901C93A6807 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 07:15:30 -0700 (PDT)
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.1/8.13.1) with ESMTP id n9AEHEWI022479 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 14:17:14 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9AEHEeE2900186 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 16:17:14 +0200
Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n9AEHDFV030824 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 16:17:13 +0200
Received: from d12ml072.megacenter.de.ibm.com (d12ml072.megacenter.de.ibm.com [9.149.166.115]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n9AEHDRS030821 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 16:17:13 +0200
In-Reply-To: <200910072139.12968.budm@weird-solutions.com>
References: <994ABFCB-3ABF-484C-9855-1EEACC663CF4@nominum.com> <200910061918.n96JI5Nv005405@cichlid.raleigh.ibm.com> <42BCDBAE-673E-44FA-B44C-42A8149D6838@nominum.com> <200910072139.12968.budm@weird-solutions.com>
X-KeepSent: 7C528424:182656B7-C125764B:004D3670; type=4; name=$KeepSent
To: Bud Millwood <budm@weird-solutions.com>
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID: <OF7C528424.182656B7-ONC125764B.004D3670-C125764B.004E7472@de.ibm.com>
From: Thomas Huth <THUTH@de.ibm.com>
Date: Sat, 10 Oct 2009 16:16:56 +0200
X-MIMETrack: Serialize by Router on D12ML072/12/M/IBM(Release 8.0.1|February 07, 2008) at 10/10/2009 16:17:13
MIME-Version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-opt-netboot-05
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 10 Oct 2009 14:15:31 -0000

Bud Millwood <budm@weird-solutions.com> wrote on 07/10/2009 21:39:12:
>
> I think Damien has a point about presentation. I also think it's easier
to
> present a subencoded option to the user with multiple (possibly required)

> suboptions than to present top-level options (just because there are so
many
> top-level options).
>
> The way our GUI works, for example, you define a subencoded option,
> then "inside it" you can only define the suboptions declared for that
parent.
> So the list of data you can put in the suboption is short and easy to
> comprehend.

Ok, these "sub-options" might work fine with a GUI, but I think the plain
text configuration files of the DHCP server gets more complicated with
sub-options. The settings then have to specified in a nested way like:

option netboot = {
   url = http://...
   params = "acpi = off ..."
   ...
}


> Thomas, you said:
>
> > In the past years, I've seen a couple of cluster installations with _a
lot_
> > of computers, ... so the scenario is really valid (though it's
something
> > that you might not use at home ;-) )
>
> How does that work in practice today with DHCPv4? Are they configured to
have
> multiple boot files somehow, or is this an attempt to solve a need that
> wasn't solved in DHCPv4?

With DHCPv4, the only way to work-around overloaded TFTP servers was:
1) Introduce a random delay in the boot process of the nodes, so that they
don't try to contact the TFTP server at the same time.
2) Add new TFTP servers and then hard-code a given set of nodes to always
boot from these servers.

There was no way to specify redundant boot servers in the DHCPv4 protocol,
so this would be a new feature in DHCPv6 which makes the configuration of
large networks much easier (you don't have to assign a given set of MAC
addresses to only one of the available server which still might to fail.
You could simply say, that all nodes should try to boot from either
server1, or if it fails try server2, then server3, etc.).

Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Erich Baier          
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294