Re: [homenet] Configuration must not be carried by the routing protocol

Dave Taht <dave.taht@gmail.com> Tue, 25 June 2013 19:58 UTC

Return-Path: <dave.taht@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3B621E80D4 for <homenet@ietfa.amsl.com>; Tue, 25 Jun 2013 12:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 gRZvTHOUttto for <homenet@ietfa.amsl.com>; Tue, 25 Jun 2013 12:58:50 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5A721E8099 for <homenet@ietf.org>; Tue, 25 Jun 2013 12:58:50 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id s9so29068650iec.41 for <homenet@ietf.org>; Tue, 25 Jun 2013 12:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IymbZ2foBeFWop6P3ow4n6yga2ndHJsh36hlHQNyCBY=; b=Arjckt0mUCzWxOLvYZHk4o0ieH+94nGagC3FUXZvsYnSKH61t6UMGuDmnHC5FRuUNC uMFfYftdNO7GK43rGmtc5lt1WtWPazQnkbq0+A/ADbaFQ0LqmOW2gSuk1F5kT+fND5B4 6CSB9yYqh6AaSn/Hf5zlNa4/Uz4ZKWv3KypIEJpLup3o1VY7ad0w7imDJGcaZGT2N15e QQgo1neMIx+uVneBF2lcGZhqG1UPseesMJhsJIufmiuzPXow2SxlUC97e29FqgIokUJx HSHbgn0JaPXk5O8h5Gtf7lCOKHTSVSuv6P4IoNY3VVl7kEbJsRM5LSSEblPwI0aPaiMC nd+Q==
MIME-Version: 1.0
X-Received: by 10.50.65.99 with SMTP id w3mr376697igs.37.1372190329852; Tue, 25 Jun 2013 12:58:49 -0700 (PDT)
Received: by 10.64.86.8 with HTTP; Tue, 25 Jun 2013 12:58:49 -0700 (PDT)
In-Reply-To: <31616.1372183404@sandelman.ca>
References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <31616.1372183404@sandelman.ca>
Date: Tue, 25 Jun 2013 12:58:49 -0700
Message-ID: <CAA93jw4mAUDBb2Q2AFqs6nyUXKnNFi9X9faWtj_cHJC5PqB2Mg@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "homenet@ietf.org Group" <homenet@ietf.org>, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Subject: Re: [homenet] Configuration must not be carried by the routing protocol
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 19:58:52 -0000

On Tue, Jun 25, 2013 at 11:03 AM, Michael Richardson
<mcr+ietf@sandelman.ca> wrote:
>
> Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
>     > Dear editors, dear group,
>
>     > After the recent thread on this list, and a number of private mail
>     > exchanges, I'm under the impression that there might be a consensus
>     > that configuration information should not be carried over the routing
>     > protocol.  In this mail, I argue that


>
>     > configuration information should be carried by a protocol separate
>     > from the routing protocol.
>
> I do not agree with this statement.

I have been on the fence on this issue for a very long time,
preferring to wait for running code, and the opportunity to run it.
Various problems, like the need for a small dhcpv6-pd capable server
have been met, but the prefix distribution issue and choice of a
routing protocol remains a sketchy one.

Do we have consensus that the majority of connections in the homenet
will be wireless?

Does anyone believe that dhcpv6 or the prefix distribution methods
discussed here are sufficient to provision wireless?

> I believe that there are significant number of people who believe that
> configuration information *MUST* be disseminated at the same time as routing
> information.

I agree that there are a significant number of people that think these
two problems are in-inextricably interlinked.

I disagree with that, but would prefer to have thoroughly proven that
they can indeed be nearly/almost/totally separated, which is not the
case. I'm glad some zOSPF code is out there now for quagga and bird,
it's long been on my todo list to experiment with.

> I understand that you'd like to see a diversity of routing protocols,
> specifically, babel and/or ahcp, and as much as I agree with the sentiment, I
> think that we need one good protocol, and that's it.

It would be nice to have one good protocol, for all definitions of "good".

However a profusion of protocols exist, and having in a configuration
protocol the ability to announce and/or select a routing protocol
would be the most flexible.

>
> If you feel that babel/ahcp (I'm not entirely sure if we need both) should be
> the homenet protocol over zOSPF:  I'm open to that discussion.
>
> I am relatively ignorant of AHCP at this point, I intend to learn by doing, I
> hope by the end of the summer.
>
>     > 3.3 A new protocol
>
>     > In the Babel experiment, I have designed a new protocol, which
>     > I called AHCP[1,2].  Since AHCP is designed to run before routing is
>     > functional, it makes minimal assumptions about the network -- it only
>     > requires each interface to have a link-local IPv6 address and to be
>     > able to participate in link-local multicast traffic.  An AHCP client
>     > implements an increasing diameter search for an AHCP server.
>
>     > The full AHCP implementation (client+server+forwarder, with support
>     > for Linux and BSD Unix), consists of 3500 lines of C and 350 lines of
>     > bourne shell code, and compiles to less than 40 kB.  Subset implemen-
>     > tations are possible.  We have found AHCP to be very robust and
>     > reasonably fast even in the presence of massive packet loss.  The
>     > traffic generated is very reasonable, even when simultaneously
>     > rebooting the whole network.
>
>     > I am not pushing AHCP as the homenet configuration protocol, since
>     > I have good hope that a variant of DHCPv6 can be used.

Actually I don't share that hope. present-day AHCP isn't sufficient
either, but it did look straightforward to add prefix distribution to
it and iterate forward as to other configuration needs as they were
better defined.

I'd like to see a conversation centered on "what is needed for a
configuration protocol" for a homenet to flush out other requirements
besides prefix distribution. As one example which I pointed out last
week, in order for windows filesharing to work properly, wins server
information needs to be propagated.

>However, I do
>     > hope that the results of the AHCP experiment can serve as useful input
>     > for this group.
>
> I near you, but I believe that we can not achieve out goals if we do not do
> configuration at the same time as loop detection and therefore routing.

Using /128 prefixes makes life tons easier.

> Specifically, I think that we will have gaping security issues which will be
> very hard to close.

The security problem has not been addressed in zOSPF either.
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html