RE: Accurate history [Re: "professional" in an IETF context]

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 03 November 2021 08:31 UTC

Return-Path: <vasilenko.eduard@huawei.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 09A5A3A11BA for <ietf@ietfa.amsl.com>; Wed, 3 Nov 2021 01:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 JaGnsnkBW4KU for <ietf@ietfa.amsl.com>; Wed, 3 Nov 2021 01:31:19 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4599A3A11C4 for <ietf@ietf.org>; Wed, 3 Nov 2021 01:31:19 -0700 (PDT)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HkfzB3Bxxz67bcp; Wed, 3 Nov 2021 16:27:50 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Wed, 3 Nov 2021 09:31:14 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Wed, 3 Nov 2021 11:31:13 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2308.015; Wed, 3 Nov 2021 11:31:13 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: RE: Accurate history [Re: "professional" in an IETF context]
Thread-Topic: Accurate history [Re: "professional" in an IETF context]
Thread-Index: AQHX0CVovVGa7jvYXUCxunxuZ8u5Aqvxc5hQ
Date: Wed, 03 Nov 2021 08:31:13 +0000
Message-ID: <23b450fb11eb4a51bb4ee837b5c52657@huawei.com>
References: <8F4B97EA-665F-4A59-B99D-791B4AB9F2F7@yahoo.co.uk> <746C1453-FFB0-46E5-ABF2-8630DC23B959@network-heretics.com> <c3e9fe1b-8e48-a364-9e25-4084dac70889@meetinghouse.net> <3a6bf8ad-5492-0942-a451-6317e8a93705@network-heretics.com> <3e685576-a230-a7c4-f371-d66a55aa820d@necom830.hpcl.titech.ac.jp> <7a087707-499f-e3bf-8701-1a58930a8a22@meetinghouse.net> <4ec32d7a-a17b-635b-91bc-4152313d6800@necom830.hpcl.titech.ac.jp> <885e62bf-7d6a-4501-a48a-e7c2cbf20382@joelhalpern.com> <e59adb61-a55c-7f5f-a60a-40bf186c139d@necom830.hpcl.titech.ac.jp> <CAC8QAceMSrfkqGTYcMNr3JargO3gxJqTaEyf02LGHd-KVeUDHw@mail.gmail.com> <6286da3e-2beb-9556-089a-2e1951573b1e@gmail.com> <59c80b60-438f-b10f-ad61-ba839f6e4f95@necom830.hpcl.titech.ac.jp> <e834916e85ea47ef94fce07c23928d2b@huawei.com> <37b299c8-e821-07e5-6240-68fb9d1ca137@gmail.com>
In-Reply-To: <37b299c8-e821-07e5-6240-68fb9d1ca137@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.192.195]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/2rTmFkdGC1aNwiPYENHq64FpT0Y>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 03 Nov 2021 08:31:24 -0000

Then why Address Resolution Protocol was needed in principle? (ND or whatever)
If the L3 address always had an L2 address inside?

The OSI was calling for layers isolation. It was a big deal for OSI.
It is not the isolation when addresses from different layers are inserted into each other.

Brian explained how it did happen: this mistake was copied from another protocol.
IMHO: it is not a good excuse.

The consequences are forever with us:
1. Filters from all vendors are 4x affected between IPv6 and IPv4. 2x was because of this decision.
2. Table sizes are 2x affected. And maybe affected 4x in the future if the IPv6 address would be expanded from 64 to 128.
3. SPRING is looking at how to "Compress SIDs". Such a label stack stresses PFE scalability 2x for not a good reason.

Wasting 2x more bits for addresses is not "free lunch".
We could waste more energy and squeeze more gates into the ASIC to overcome the scalability problem created.
IPv6 is anti-green technology as a result.
If it is needed to process more bits - it is the cost for nature.

By the way, IPv6 is close to "64-bit addressing technology" now. In reality, it is a little bigger because bits are not wasted for IDs on the subnet.
All these calculations of addresses per every atom on the Earth are wrong. Real address space is 2^64 smaller.
The current practice to "waste as much IPv6 as possible for every design" would fire back in a few decades.
Or a big revamp would be needed to expand from 64 to 128 bits. CIDR again.

Eduard
-----Original Message-----
From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: Tuesday, November 2, 2021 11:08 PM
To: ietf@ietf.org
Subject: Accurate history [Re: "professional" in an IETF context]

On 03-Nov-21 05:45, Vasilenko Eduard wrote:
> +1.
> It was a big mistake to break OSI model and include L2 address (MAC) inside L3 address (IPv6).

I think you are not familiar with the CLNP NSAPA GOSIP addressing model. As RFC1526 clearly explains, the CLNP address architecture proposed for the Internet embodied an ID field that could be an IEEE MAC address (see section 3.1 in particular). That's how DECnet/OSI worked, too. (And Novell Netware, copied from Xerox PUP, a.k.a. XNS.)

We didn't break the OSI model, we copied it.

> Half of the address bits were wasted.

No, we *doubled* the address size to accomodate the ID field. Most people at the time expected a 64 bit address. I believe that it was the 20 byte GOSIP address that made the 16 byte IPv6 address thinkable.

    Brian

> Many people are coming and coming asking that they would like too to get some bits of IPv6 address for some new protocol.> Eduard