RE: KHALED Routing Protocol (KRP).

Khaled Omar <eng.khaled.omar@hotmail.com> Fri, 28 April 2017 13:16 UTC

Return-Path: <eng.khaled.omar@hotmail.com>
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 35E301292FC for <ietf@ietfa.amsl.com>; Fri, 28 Apr 2017 06:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.146
X-Spam-Level:
X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 CUaf61Okg-Uk for <ietf@ietfa.amsl.com>; Fri, 28 Apr 2017 06:16:06 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-oln040092069052.outbound.protection.outlook.com [40.92.69.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6FF129C21 for <ietf@ietf.org>; Fri, 28 Apr 2017 06:12:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xg5G2dRaSSkGABgv7reNZKzaRr+jSBjjiCnO9Z2GvIw=; b=r91jSb+FS5+vR32QoRwCUr3Lz5uHnxdvSZh95c0OF581SSReiccqlZcAAm/tgre+DeRUslhTK7VbUW1tNGb4RFWzfwY49utUmUUH6y5OlCVvUCIGGgaN5P5IGghrimMId2WZv4CoZ4ubjO7VhzLbWVjXMQdFJOY6Wso4yQMDuxFupJNUJNsSWKZ8bQ95s109h+eg5Q178C2HL2dSLthbeb57mf42XkjTIhnB91ii+Wdcfq4tAyq4Y63Ig1S1LxbzmGyoa8/BseQdYaGKd5skEzt5HOLl7jUwXpaUW/bCSe4k36QaO+Y45oNJojfBECaxaJiaswZDXJN6MWoK1H6m8w==
Received: from HE1EUR02FT055.eop-EUR02.prod.protection.outlook.com (10.152.10.53) by HE1EUR02HT034.eop-EUR02.prod.protection.outlook.com (10.152.11.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1047.9; Fri, 28 Apr 2017 13:12:13 +0000
Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com (10.152.10.55) by HE1EUR02FT055.mail.protection.outlook.com (10.152.11.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.9 via Frontend Transport; Fri, 28 Apr 2017 13:12:13 +0000
Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::167:4fb:cc08:25a5]) by AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::167:4fb:cc08:25a5%19]) with mapi id 15.01.1047.021; Fri, 28 Apr 2017 13:12:13 +0000
From: Khaled Omar <eng.khaled.omar@hotmail.com>
To: Lee Howard <lee@asgard.org>
CC: "ietf@ietf.org" <ietf@ietf.org>
Subject: RE: KHALED Routing Protocol (KRP).
Thread-Topic: KHALED Routing Protocol (KRP).
Thread-Index: AdK+G23caKcCxRD+Rv6ktBX4ggsYAQCAWvGAAAB/igA=
Date: Fri, 28 Apr 2017 13:12:12 +0000
Message-ID: <AM4PR0401MB2241174F682EE6776E9E27E6BD130@AM4PR0401MB2241.eurprd04.prod.outlook.com>
References: <CAKHUCzxK9-McSigoCn-4MvWM-ZPjTzQ+xUj8eB9U1yrA8otGKA@mail.gmail.com> <AM4PR0401MB2241DFDF2E27B9208F37B0D1BD130@AM4PR0401MB2241.eurprd04.prod.outlook.com> <D528AF97.7A8F6%lee@asgard.org>
In-Reply-To: <D528AF97.7A8F6%lee@asgard.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: asgard.org; dkim=none (message not signed) header.d=none;asgard.org; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:C853A4D6E4A8A287103640BA1CA94554D9EDF42E811CD9B1DDA5C2DB619C08EF; UpperCasedChecksum:DAF9F236987594609ED4FAF7651184BB9E4AA37CEB450B3CC05BC4A47873CDD7; SizeAsReceived:8181; Count:42
x-tmn: [hKjgk9CLtH68s+fj2sbGpU+v0LUUVSaS]
x-microsoft-exchange-diagnostics: 1; HE1EUR02HT034; 5:n7qiWANpIz7eFY5ry03/t0tca0fUgHS4InF2JCNl1hBpHDtxlTrBgAqJ/d2OpBfYhRQmEk8akKhBKTZrGCqsBMovUQdFhAs6dMeZEPpFrKMqbGmDnFiN6czdm3ysZreTiXccWOwpEidxa1ZYnzsjLg==; 24:h596KhsUM5Y5jBekHq/T8LFjAeSIZK5OxAf9ZmcrRK3UfyRdZ+3eVuHq1zP5m325nQDKvWNuZ13V9701Qzyj+zP/wKvyJ0QEG9WYmbfWZk4=; 7:Z6kAux2f3h5taiBCv+mRdCB6FHe43hVwj5kWWpN6IYLggxt7KI+mJ6t67LqZV80dgBjFmddBa06CC4zdHbYADnPNmqyFIc16bZpOG14hDzooLQ9PYbgoSqRK/qI5W0zU/5bKD9sC8SEZM4do6IvY8KlQTw6MhbR5EYEyY9aU8RMoazP51UhzOdhnaNFQrxgaAxs4L5zeOfgyZ9EH/jpn4Wh2VQaWlDmjuKNHyvxvRnb9DMT2mdEuRNmOLWvPiaH++IZrpAqPMmgkeea2Yvql3vs2k2LKtkkvcNPk46P70CTDgSLb3Ezc50j6MCnGIdIl
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR02HT034; H:AM4PR0401MB2241.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: a2d86f5b-a072-483e-08d4-08d48e382f7c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:HE1EUR02HT034;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HE1EUR02HT034; BCL:0; PCL:0; RULEID:; SRVR:HE1EUR02HT034;
x-forefront-prvs: 029174C036
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM4PR0401MB2241174F682EE6776E9E27E6BD130AM4PR0401MB2241_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2017 13:12:13.1292 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR02HT034
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/RZxLSKEqrJuhSu866_K9C6g1Fq0>
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 13:16:08 -0000


KRP router Forwarding Table (FT):


Local KRP ASN

Remote KRP ASN

RBR KRP ASN

Best AS Path

Output Interface

Next-hop IP address



This is the used KRP Forwarding Table, it lists KRP ASNs and the Best AS path from the local KRP ASN and every single destination KRP ASN.

When the packet travels between KRP ASNs, it uses the already existing IGP Routing Table that lists full local prefixes/subnets within this local KRP ASN until reaching the RR or the RBR.

Regarding IPv4, the 1st two octets are used as KRP ASN for ISPs but still an issue for enterprises because the KRP ASN must be unique and this is under development.

The Best best route means respectively:


1)      The shortest AS path.

2)      The lowest IGP metric route.

From: Lee Howard [mailto:lee@asgard.org]
Sent: Friday, April 28, 2017 2:42 PM
To: Khaled Omar; ietf
Subject: Re: KHALED Routing Protocol (KRP).



From: ietf <ietf-bounces@ietf.org<mailto:ietf-bounces@ietf.org>> on behalf of Khaled Omar <eng.khaled.omar@hotmail.com<mailto:eng.khaled.omar@hotmail.com>>
Date: Friday, April 28, 2017 at 8:08 AM
To: ietf <ietf@ietf.org<mailto:ietf@ietf.org>>
Subject: Fw: KHALED Routing Protocol (KRP).

Regarding the difference between tables, KRP within each region uses a table of only RBRs and RRs, the table is not listing prefixes because KRP uses the information stored on every single IP address and the IGP routing table, also, the Forwarding table details of one region is not advertised to other regions because they don't need to know it, enough to know how to reach the RBR and then it can deliver the packet faster and correctly.

Sorry, you're carrying full routes for every /32 and every /128 in your IGP?



KRP will not require renumbering (reallocation) of IP addresses after the modification made to the 1st version of the draft that used the 1st two groups of IPv6 addresses as the KRP ASN, but the 2nd version used the middle two groups, and that will make the usage of KRP easier.

What about IPv4?



Finally, don't stop on what you think is not applicable, share your thoughts to add a solution to make things applicable thats the aim of the discussion, because KRP can route packets successfully from the source to the destination using the Best best route and with the lowest table entries for faster routing decisions.

Define "Best best."
Shortest AS hops? Fewest intermediate devices? Cheapest link? Least saturated link? Hot potato? Lowest packet one-way latency?

I agree with Dave; the 6renum WG published rfc7010 IPv6 Site Renumbering Gap Analysis and then shut down; filling those gaps would be useful.

Lee




-------- Original Message --------
Subject: Re: KHALED Routing Protocol (KRP).
From: Dave Cridland
To: Khaled Omar
CC: ietf@ietf.org<mailto:ietf@ietf.org>


On 26 April 2017 at 00:27, Khaled Omar 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.