Re: KHALED Routing Protocol (KRP).

Dave Cridland <dave@cridland.net> Fri, 28 April 2017 09:03 UTC

Return-Path: <dave@cridland.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26975129C48 for <ietf@ietfa.amsl.com>; Fri, 28 Apr 2017 02:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net
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 xQHSBq1y-0Mg for <ietf@ietfa.amsl.com>; Fri, 28 Apr 2017 02:03:32 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84D5129436 for <ietf@ietf.org>; Fri, 28 Apr 2017 02:00:35 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id l9so30029758wre.1 for <ietf@ietf.org>; Fri, 28 Apr 2017 02:00:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/NgDG6VYQG0R4JChjTui301jI7ucOlAUzE4UWnVzuEg=; b=R5OcdhQp14ffejJ6Sz3p5PjIakZ/uDaONVH2qaT38kNw4N4/0UaW2bRsT1FhGl7/f4 HaSSrbZshNwoOgUhGT4NQJJ5nnqPJESPgPItAB4Ib4mMwsrIcbwhF58OwEmZs9A2pciM 83gKhP+O7bdJUr2ktdEFhZgK/fmCLd8yTEwCw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/NgDG6VYQG0R4JChjTui301jI7ucOlAUzE4UWnVzuEg=; b=dmnp8hdUmH2SAO6FbWtr0V0k2Id+jL+BkatAwvc4wwJwT3Vy8gd6CPaoxMG15XuHr+ Y/u4kZcLPEUB7/bKfVmx6z38XaFj7+I23KbzNPGiLINusZwzQL1+W7+BrOmY/RVT1I3T isqxR2CtoIBIET4B1Q1Mm7F5+2m7nsRIQC3VdQTYFObZDcyGn+2rNLhpzo+JSeHAXL4y pvsy15llGHuX2OV4vzQs6k3dlXd1qBgZ+5d4GtXBTn9etD5KCjMOLwKLmVvnhKHjHWyz 0JsJP4KazNxv4iUImod32ETbQ+pO49GkXs7AFw3um3/k0I3yXinU5CoOstuGR0Uob1Bm qyxg==
X-Gm-Message-State: AN3rC/5LfzdU5ZfE5Z9FUCuk9lxeXEqgR6QTSGJEPkuvRho9J/6VHg+p QyWvbbTfneepaSSMC8CFjoB9YmWpfYp4vDI=
X-Received: by 10.223.135.216 with SMTP id c24mr6601900wrc.109.1493370034385; Fri, 28 Apr 2017 02:00:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.135 with HTTP; Fri, 28 Apr 2017 02:00:33 -0700 (PDT)
In-Reply-To: <AM4PR0401MB2241F91F390678CE3C0F3193BD1E0@AM4PR0401MB2241.eurprd04.prod.outlook.com>
References: <AM4PR0401MB2241F91F390678CE3C0F3193BD1E0@AM4PR0401MB2241.eurprd04.prod.outlook.com>
From: Dave Cridland <dave@cridland.net>
Date: Fri, 28 Apr 2017 10:00:33 +0100
Message-ID: <CAKHUCzxK9-McSigoCn-4MvWM-ZPjTzQ+xUj8eB9U1yrA8otGKA@mail.gmail.com>
Subject: Re: KHALED Routing Protocol (KRP).
To: Khaled Omar <eng.khaled.omar@hotmail.com>
Cc: "ietf@ietf.org" <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/sHhXeBMh93dItaTHfAbRGvSDUP8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Apr 2017 09:03:34 -0000

On 26 April 2017 at 00:27, Khaled Omar <eng.khaled.omar@hotmail.com> wrote:
> https://datatracker.ietf.org/doc/draft-omar-krp/

I like this idea, but I think it's sufficiently similar to the
original aim of EGP/BGP that it's already been proven impractical, and
moving to it would also be impractical. I am not a routing expert, so
I'll cheerfully wait being shot down by others, but this is my
rationale:

The reason why we have large routing tables within BGP routers is
mostly that ASNs now consist of many more prefixes than were
originally expected, and so the prefixes do not aggregate well enough.

This proposal involves, essentially, renumbering the entire internet
(which is very difficult in practical terms), such that aggregation
then works more efficiently. However, history has shown that while
this would work for the short term, it would require continuous
renumbering in response to many factors (new addresses, corporate
mergers, etc) in order to maintain its efficiency.

Since we have not solved renumbering very effectively in the first
place, I feel that this is not worth working on.

I would, however, suggest that addressing renumbering would be an
excellent use of your time. A viable solution to renumbering large
public networks would mean that the BGP table would shrink, by the
same logic as above.

That is, if we had a method for renumbering continuously, then it
would improve the efficiency of BGP as well, to almost the same
extent, without incurring the initial internet-wide renumbering
effort.

Finally, I would note that while routing tables are large, the
internet still functions - this may not be the best use of your time
therefore.

Dave.