RE: Internet Drafts' Destiney.

Khaled Omar <eng.khaled.omar@outlook.com> Tue, 29 May 2018 18:47 UTC

Return-Path: <eng.khaled.omar@outlook.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 4DAFA12EB20 for <ietf@ietfa.amsl.com>; Tue, 29 May 2018 11:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 VJuEnthfPuH3 for <ietf@ietfa.amsl.com>; Tue, 29 May 2018 11:47:56 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068037.outbound.protection.outlook.com [40.92.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5346F12EB26 for <ietf@ietf.org>; Tue, 29 May 2018 11:47:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fEkvi59r9IN/VgsQLN/TRT7BsZiCIjiyFxuFXvo8f94=; b=T6RXBXH5Y1jnlBjkga56xVXzTL3T/mLRRqcMLE/+iyEb0D6vhE50aZuFkss+c76/KiVhHwK5ztQ2uXqhnuFh76WzxVruyiGClH5tG/0iwPA44RioQRvWVk5CP6L4AL/wvvf9myfQ2XIomHs3HsOApZbjOiA3Afts5BVS4JxPvItKmEZIg9ja8xUVxpYmpKqSS/PG9bAQHNwwhpELMAbSKovoEqEEQFkeN7vXLFDWl4DdNlSzPkZyiZOCdzDVTWxdAJBUYbYyPL7zU/MmoVxfJibYEBltgCmKllXMxf8/LUEQftemnUFzJDXjyAE1DqunlP7j7MAO18a/S4yGYk17yA==
Received: from AM5EUR02FT044.eop-EUR02.prod.protection.outlook.com (10.152.8.59) by AM5EUR02HT172.eop-EUR02.prod.protection.outlook.com (10.152.9.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.820.8; Tue, 29 May 2018 18:47:52 +0000
Received: from HE1P190MB0122.EURP190.PROD.OUTLOOK.COM (10.152.8.52) by AM5EUR02FT044.mail.protection.outlook.com (10.152.9.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.820.8 via Frontend Transport; Tue, 29 May 2018 18:47:52 +0000
Received: from HE1P190MB0122.EURP190.PROD.OUTLOOK.COM ([fe80::a97a:e2b1:f8f:5142]) by HE1P190MB0122.EURP190.PROD.OUTLOOK.COM ([fe80::a97a:e2b1:f8f:5142%17]) with mapi id 15.20.0797.017; Tue, 29 May 2018 18:47:52 +0000
From: Khaled Omar <eng.khaled.omar@outlook.com>
To: Bernardo Soares <bsoares.it@gmail.com>
CC: Nick Hilliard <nick@foobar.org>, Randy Bush <randy@psg.com>, IETF Rinse Repeat <ietf@ietf.org>
Subject: RE: Internet Drafts' Destiney.
Thread-Topic: Internet Drafts' Destiney.
Thread-Index: AdP18k6rPJX7Rk6lT7uaB+6o8j29YQAMGV5gACGyI9AAALnhAAAAE6SAAAN03QAADBlbAAATpD8AAA+jcEAAAK0PAAAAP9bg
Date: Tue, 29 May 2018 18:47:52 +0000
Message-ID: <HE1P190MB012214F5BB0675B756B8DF27AE6D0@HE1P190MB0122.EURP190.PROD.OUTLOOK.COM>
References: <AM5PR0401MB260963E616A6312FFE23C06EBD6F0@AM5PR0401MB2609.eurprd04.prod.outlook.com> <F04ED1585899D842B482E7ADCA581B8469646E54@newserver.arneill-py.local> <HE1P190MB0122B8E77A642DEDBF4F018AAE6E0@HE1P190MB0122.EURP190.PROD.OUTLOOK.COM> <alpine.OSX.2.01.1805281046530.26368@ole-pro-2.local> <HE1P190MB012227711961EB4D4343C761AE6E0@HE1P190MB0122.EURP190.PROD.OUTLOOK.COM> <94803d56-437b-a8d9-cdb3-c1b87fbd6e1c@foobar.org> <m2h8mrqmxz.wl-randy@psg.com> <46f96301-e96d-7084-9253-404c0ceb0052@foobar.org> <HE1P190MB0122183060514DD7D7429EE1AE6D0@HE1P190MB0122.EURP190.PROD.OUTLOOK.COM> <CAABUMRjPGQGuZs1Q0eu2byZuuua4Pbe1P_puXb4kvgO-OpDm6Q@mail.gmail.com>
In-Reply-To: <CAABUMRjPGQGuZs1Q0eu2byZuuua4Pbe1P_puXb4kvgO-OpDm6Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:2F8535BFA60D4149E4FEAA78F542E8C71C3D48C81012AA78E8F0E7A6493AD1F1; UpperCasedChecksum:0BC8AFE0C6ADC19BC8140A30167F3632C0C4C31CFA10FA40B6F26F2DE49B509D; SizeAsReceived:7713; Count:46
x-tmn: [OlFgJwjM7HmUgC6QCmqTlzsaLYk6UV5Q]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5EUR02HT172; 7:Y2zqWM4ZpCy0UvVqvSk6xiMyUcIXZ/UiK311Vq2Mm/SKWCsgDyAXSNztg3TPF+OcJQnZ1uIDz5BdBHicSnciWuI2f5MM84u4z+6H8JH1Yoa+NB9y+PvEm55j41a0mh4Wxr9RAIrukU5YTxv02++YQq6UfE0n25h6D+5af7p2o+X/0biv1m8w9UXf+Vc+3wxPRd/AecEXRrL3zYtkUM/B21ZQiRn/8XRTq/EWNkBlj7iDM3ErnMxxQaut8amSWytE
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045); SRVR:AM5EUR02HT172;
x-ms-traffictypediagnostic: AM5EUR02HT172:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:AM5EUR02HT172; BCL:0; PCL:0; RULEID:; SRVR:AM5EUR02HT172;
x-forefront-prvs: 0687389FB0
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(13464003)(199004)(189003)(6916009)(20460500001)(82202002)(33656002)(966005)(68736007)(5660300001)(2900100001)(236005)(4326008)(74316002)(39060400002)(87572001)(229853002)(6246003)(54906003)(426003)(26005)(25786009)(45080400002)(3660700001)(6436002)(54896002)(7696005)(97736004)(104016004)(476003)(93886005)(8676002)(6306002)(446003)(6346003)(55016002)(11346002)(86362001)(19609705001)(5250100002)(81156014)(486006)(59450400001)(102836004)(606006)(76176011)(106356001)(105586002)(8936002)(3280700002)(790700001)(21615005)(14454004)(53546011)(99286004); DIR:OUT; SFP:1901; SCL:1; SRVR:AM5EUR02HT172; H:HE1P190MB0122.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:;
received-spf: None (protection.outlook.com: outlook.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eng.khaled.omar@outlook.com;
x-microsoft-antispam-message-info: E9xXiSK/45jtm+nQFneFLvmqvUgrHaHIEHuilauPmQTd651BHqsbSLjqpQdMCM+NKcA28Z/bJ9YG2iV7oA9PcLnb1T01Xa6oD4pp+eD0/UI8X/Xg5z1dSaP43s31YyROeSSLWFruLHHN6UYp91vKcDyF+6RKV/n6mKSzeR3G+isYWovT+4WBVnjWtYaTWPRE
Content-Type: multipart/alternative; boundary="_000_HE1P190MB012214F5BB0675B756B8DF27AE6D0HE1P190MB0122EURP_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 022d63cd-1082-49bf-d75a-08d5c594aeee
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: dd759f05-a917-4aa0-a2f5-4cc35c50e0c8
X-MS-Exchange-CrossTenant-Network-Message-Id: 022d63cd-1082-49bf-d75a-08d5c594aeee
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: dd759f05-a917-4aa0-a2f5-4cc35c50e0c8
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2018 18:47:52.3044 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT172
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/puSQBfDwOshzRRSWG0_jYP_A4EM>
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: Tue, 29 May 2018 18:48:00 -0000

> why not bgp?

As mentioned on the ID … short routing table, the use of the efforts already made by the IGP within each AS, use dedicated links for different traffic classes, and the use of the stored information within each IP in the routing process.

> in case of inter-as routing exchange, no KRP on one side. does it make sense using two distinct EGPs?

KRP works on both sides … it is a replacement to the bgp except using its AS path selection using the best path algorithm.

From: Bernardo Soares [mailto:bsoares.it@gmail.com]
Sent: Tuesday, May 29, 2018 8:28 PM
To: Khaled Omar <eng.khaled.omar@outlook.com>
Cc: Nick Hilliard <nick@foobar.org>; Randy Bush <randy@psg.com>; IETF Rinse Repeat <ietf@ietf.org>
Subject: Re: Internet Drafts' Destiney.

> It is not actually a hierarchical address allocation, it is some kind of organizing the allocation mechanism, the way KRP uses can be applied to the recent allocation mechanism, 1st hex digit of the second group of an IPv6 address determines on which region you are located, the 2nd and 3rd groups of an IPv6 address determines the KRP ASN, no changes will be applied to the recent allocation way.

why not bgp?

> KRP describes the full routing mechanism from the source to the destination, other details I know should be added but the main idea is described on the KRP ID.

in case of inter-as routing exchange, no KRP on one side. does it make sense using two distinct EGPs?




On Tue, May 29, 2018 at 3:20 PM, Khaled Omar <eng.khaled.omar@outlook.com<mailto:eng.khaled.omar@outlook.com>> wrote:
> KRP: describes some form of hierarchical address allocation mechanism but there are no details provided about the "protocol" itself.  There isn't anything to review here because the draft has no workable content.

It is not actually a hierarchical address allocation, it is some kind of organizing the allocation mechanism, the way KRP uses can be applied to the recent allocation mechanism, 1st hex digit of the second group of an IPv6 address determines on which region you are located, the 2nd and 3rd groups of an IPv6 address determines the KRP ASN, no changes will be applied to the recent allocation way.

KRP describes the full routing mechanism from the source to the destination, other details I know should be added but the main idea is described on the KRP ID.

> hence the request for sergeant-at-arms to intervene again.

We can continue the discussion privately so we do not bother the list with many e-mails.

Khaled



-----Original Message-----
From: ietf [mailto:ietf-bounces@ietf.org<mailto:ietf-bounces@ietf.org>] On Behalf Of Nick Hilliard
Sent: Tuesday, May 29, 2018 12:41 PM
To: Randy Bush <randy@psg.com<mailto:randy@psg.com>>
Cc: eng.khaled.omar@hotmail.com<mailto:eng.khaled.omar@hotmail.com>; IETF Rinse Repeat <ietf@ietf.org<mailto:ietf@ietf.org>>
Subject: Re: Internet Drafts' Destiney.

Randy Bush wrote on 29/05/2018 02:18:
> maybe do an actual review?

There's nothing to say that hasn't already been said by many other people, but let's rinse and repeat anyway:

IPv10: the proposals ignore all previous discussions about ipv4 to ipv6 compatibility schemas.  There's been a good deal of discussion about this over the years, and the general opinion is that direct ipv4-ipv6 compatibility shims are unworkable for a variety of reasons.  Brian Carpenter sent this helpful and constructive email in Nov 2016:

https://www.ietf.org/mail-archive/web/ietf/current/msg99798.html

This still stands today.

KRP: describes some form of hierarchical address allocation mechanism but there are no details provided about the "protocol" itself.  There isn't anything to review here because the draft has no workable content.

The problem isn't a lack of reviews, it's that these ideas have been discussed repeatedly at the ietf over many years and the consensus is that they are unworkable.

Khaled has not gone to the effort of looking into why they were unworkable, nor has he developed his proposals to the point that they are actually testable in a lab environment (at which point it would become clear that they are unworkable in the real world).

Khaled apparently isn't interested in listening to this feedback.  The feedback and reviews are there.

We've had ~300 emails on ietf@, and nothing has progressed beyond what was stated in Nov 2016, at which stage Khaled was warned multiple times by the sergeant-at-arms of the time that his attempts to bring these topics up on the ietf@ mailing list were not ok:

https://www.ietf.org/mail-archive/web/ietf/current/msg99875.html
https://www.ietf.org/mail-archive/web/ietf/current/msg99932.html

.... hence the request for sergeant-at-arms to intervene again.

Nick